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Preface 


The  goal  of  my  research  was  to  develop  an  impressive  algorithm  animation 
system  using  the  techniques  of  modern  software  engineering.  The  AFIT  Algorithm 
Animation  Research  Facility,  or  AAARF,  is  the  result  of  that  research.  As  for  its 
impressiveness,  few  events  in  academia  draw  a  crowd  of  excited  researchers  as  quickly 
as  the  thrill  of  an  AAARF  algorithm  race.  With  respect  to  the  development,  the 
classic  life-cycle  paradigm  for  software  engineering  was  used;  IDEFo  diagrams,  enu¬ 
merated  requirements  specifications,  object-oriented  design  concepts,  and  structure 
charts  were  used  to  document  the  effort.  Over  10,000  lines  of  code  were  written, 
roughly  half  of  which  are  comments. 

I  especially  want  to  thank  Marc  Brown  for  his  pioneering  work  in  elg'^rithm 
animation.  His  book.  Algorithm  Animation^  provided  ideas  for  many  of  AAARF’s 
features.  AAARF  differs  from  Brown’s  BALSA  system  in  that  it  uses  multiple 
processes  to  animate  algorithms  and  supports  remotely-hosted  algorithm  processes. 

I  want  to  thank  my  advisor.  Dr  Gary  Lament,  for  allowing  me  almost  complete 
freedom  over  the  design  and  implementation  of  AAARF,  but  providing  just  the 
right  nudges  to  keep  me  from  using  that  freedom  to  "hang”  myself.  I  must  also 
thank  Major  Phil  Amburn  and  Dr  Thomas  Hartrum  for  their  excellent  instruction  in 
Computer  Graphics  and  Software  Engineering.  Without  the  use  of  Major  Amburn’s 
specially-configured  Sun4  workstation,  AAARF  would  not  be  what  it  is  toaa  • 

I  want  to  acknowledge  my  gratitude  to  nearly  everyone  I  know  -  my  family  in 


Florida,  my  friends  in  California,  and  the  Friday  night  gang  here  in  Dayton.  Without  _ 

Ft 

their  support  and  comradery,  I  couldn’t  get  through  life  much  less  a  thesis.  Finally,  j ' 
if  anyone  deserves  gratitude,  it’s  my  son,  Bryan,  who  endured  a  year  with  ^father  ^ 
preoccupied  with  “something  called  AAARF.”  Thanks,  Bryan. 


Keith  Carson  Fife  - 
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Abstract 

Traditionally,  software  engineers  have  described  algorithms  and  data  structures 
using  graphical  representations  such  as  flow  charts,  structure  charts,  and  block  dia¬ 
grams.  These  representations  can  give  a  static  general  overview  of  an  algorithm,  but 
they  fail  to  fully  illustrate  an  algorithm’s  dynamic  behavior.  Researchers  have  begun 
to  develop  systems  to  visualize,  or  animate,  algorithms  in  execution.  The  form  of  the 
visualization  depends  on  the  algorithm  being  examined,  the  data  structures  being 
used,  and  the  ingenuity  of  the  programmer  implementing  the  animation. 

This  study  chronicles  the  development  of  the  AFIT  Algorithm  Animation  Re¬ 
search  Facility  (AAARF).  The  goal  of  the  study  is  (1)  to  de/elop  a  method  for 
developing  algorithm  animations  and  (2)  to  develop  an  environment  in  which  the 
animations  can  be  displayed.  The  study  emphasizes  the  application  of  modern 
software  engineering  techniques.  The  development  follows  a  classic  life-cycle  soft¬ 
ware  engineering  paradigm:  requirements,  design,  implementation,  and  testing.  An 
object-oriented  approach  is  used  for  the  preliminary  design.  The  system  is  im¬ 
plemented  with  the  C  programming  language  on  a  Sun  workstation  and  uses  the 
SunView  window-based  environment. 

A  framework  is  proposed  for  developing  edgorithm  animations  that  minimizes 
the  development  time  for  client-progrcimmers.  The  framework  also  ensures  that 
end-users  are  presented  a  consistent  method  for  interacting  with  the  animations. 
The  algorithm  animation  environment  provides  end-users  with  a  variety  of  control 
and  viewing  options:  multiple  algorithms,  multiple  views,  simultaneous  control  of 
algorithms,  and  animation  environment  control.  Three  levels  of  execution  are  used 
to  provide  multiple  algorithm  animations  and  multiple  views  of  algorithms.  The 
animation  manager  and  view  generators  must  reside  on  the  Sun  workstation,  but 
the  algorithms  can  reside  on  any  network-connected  host. 
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1.1  Background 

An  algorithm  animation  system  is  a  “software  microscope”  for  analyzing  the 
dynamic  behavior  of  algorithms  and  their  related  data  structures.  By  dynamically 
displaying  a  graphical  representation  of  an  executi  .g  algorithm’s  current  state,  ani¬ 
mation  can  reveal  properties  of  the  algorithm  that  are  not  easily  expressed  m  pseudo¬ 
code,  flow  charts,  or  data-flow  diagrams.  In  fact,  unknown,  perhaps  unwanted,  prop¬ 
erties  can  be  revealed  [6:5j,  helping  software  engineers  “see”  ways  to  realize  more 
efficient  and  effective  algorithms.  As  an  educational  tool,  algorithm  animation  can 
help  students  understand  new  and  difEcult  algorithms  by  providing  a  means  for  vi¬ 
sualizing  and  interacting  with  algorithms  as  they  execute.  As  a  production  tool, 
animation  provides  a  means  for  visually  analyzing  the  impact  of  particular  algo¬ 
rithms  on  specific  problems  and  data  sets,  helping  develop  new  and  better  solutions 
for  increasingly  difficult  programming  challenges. 

1.2  Purpose 

The  purpose  of  this  study  is  (1)  to  develop  a  methodology  for  creating  algo¬ 
rithm  animations  and  (2)  to  develop  an  environment  for  controlling,  displaying,  and 
interacting  with  the  animations.  This  dual  purpose  reflects  the  needs  of  two  types 
of  users:  “client-programmers”  and  “end-users”  [6:6]. 
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Client-programmers  are  concerned  with  implementing  the  algorithm  anima¬ 
tions  with  which  end-users  interact.  With  respect  to  client-programmers,  the  goal 
of  this  study  is  to  create  a  program  development  environment  which  provides  a  con¬ 
sistent  interface  to  the  algorithm  animation  system  and  supports  reusable  software 
modules.  The  programmer  '•hould  not  have  to  reimplement  modules  common  to  sev¬ 
eral  algorithms,  such  as  window  management,  user-ip*^erface,  and  display  functions 
[6:7].  Further,  the  development  environment  should  provide  a  set  of  primitives  that 
are  natural  to  animation;  for  example,  smooth  continuous  movement  along  a  path 
123|, 

End-users  view  and  interact  with  the  animations  at  a  computer  workstation. 
With  respect  to  end-users,  the  goal  of  this  investigation  is  to  provide  an  algorithm 
animation  run-time  environment  which  provides  a  consistent  method  for  interacting 
with  the  animations.  After  animating  one  algorithm,  end-users  should  be  able  to 
animate  any  algorithm,  regardless  of  the  type  of  algorithm  or  the  client-programmer 
of  the  animation  [6:7]. 

1.3  Problem 

In  general,  the  problem  is  to  develop  a  method  for  animating  any  algorithm. 
Three  general  approaches  for  solving  the  problem  are  proposed: 

•  Client-Programmer  Based.  Develop  a  libreiry  of  support  procedures  which 
the  client-programmer  uses  along  with  a  set  of  algorithm-specific  procedures  to 
produce  an  executable  algorithm  animation.  This  approach  creates  a  serarate 
executable  program  for  every  algorithm  animation.  No  provisions  are  made  for 
controlling  or  viewing  multiple  algorithms,  and  the  user  has  no  way  of  knowing 
what  animations  are  available.  Though  client-programmers  can  easily  develop 
algorithm  animations,  the  end-user  interface  is  poor. 
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•  End-User  Based.  Develop  an  animation  system  which  animates  any  algo¬ 
rithm  based  on  some  set  of  parameters  which  describe  the  slg.,rithm.  The 
parameters  are  developed  by  the  client-programmer.  This  approach  requires 
only  one  executable  program  with  a  separate  parauneter  list  for  every  algorithm 
to  be  animated.  The  system  manages  the  parameter  lists  so  that  end-users  can 
easily  select  from  a  collection  of  available  algorithms.  The  system  provides  a 
mechanism  for  controlling  and  viewing  multiple  animations.  But  since  the 
animations  are  generated  based  on  a  set  of  parcimeters  which  describe  the 
algorithm,  the  animations  are  necessarily  simple  and  potentially  ineffective. 
Though  complex  animations  might  be  possible,  the  parameterized  description 
would  take  a  herculean  effort  to  produce.  This  approach  provides  a  better 
end-user  interface,  but  presents  a  problem  for  the  client-programmer. 

•  Dual-Interface.  The  third  approach  incorporates  aspects  of  both  the  end-user 
based  and  client-programmer  based  approaches.  Develop  a  system  through 
which  a  user  can  select,  execute,  and  control  individual  animations,  each  of 
which  is  a  sepcirate  executable  procedure.  The  client-programmer  develops  the 
executable  procedures  with  the  help  of  a  library  of  algorithm  animation  support 
functions.  This  approach  considers  both  the  end-user  and  client-programmer 
interfaces. 

This  investigation  pursues  the  dual-interface  approach.  The  goad  is  to  develop 
an  algorithm  animation  environment  which  presents  an  easy-to-use,  functional  inter¬ 
face  to  end-users,  and  provides  an  effective  means  for  managing  algorithm  animations 
within  the  animation  environment  for  client-programmers. 
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1.4  Scope 

Although  many  algorithms  can  be  animated  to  test  and  demonstrate  the  sys¬ 
tem,  the  goal  of  this  project  is  not  algorithm  research.  Rather,  the  goal  is  to  develop  a 
system  on  which  algorithm  research  can  be  conducted  and  to  develop  a  methodology 
for  creating  algorithm  animations.  The  emphasis  is  not  on  product  completeness, 
but  on  the  proper  application  of  modern  software  engineering  principles  toward  the 
development  of  that  product. 

1.5  Assumptions 

1.  Algorithm  animation  displays  cannot  be  created  automatically.  Algorithm  an¬ 
imation  can  do  more  than  just  monitor  the  value  of  a  program  vaxiable;  it 
can  present  abstract  graphiczd  representations  of  an  algorithm’s  fundamental 
operations.  These  fundamental  operations  cannot  be  deduced  for  an  arbitrary 
algorithm;  they  must  be  defined  by  a  programmer  familiar  with  the  operation 
of  the  algorithm  (6:18).  Likewise  the  selection  and  development  of  a  graphi¬ 
cal  representation  cannot  be  performed  automatically.  Some  specialized  data 
structures  and  algorithms  require  unique  representations  to  make  aspects  of 
their  execution  understandable  [6:19]. 

2.  Any  algorithm  can  be  animated.  All  algorithms  manipulate  some  non-empty 
set  of  data  structures,  and  at  some  level  of  abstraction,  every  data  structure 
can  be  represented  graphically  -  monitoring  and  displaying  the  data  struc¬ 
ture’s  vEUue  being  the  lowest.  However,  arbitrary  algorithm  animations  are  not 
necessarily  effective.  Many  factors  impact  the  effectiveness  of  an  animation: 
meaningful  input  data,  proper  identification  of  interesting  events,  meaningful 
views  of  the  algorithm  state,  appropriate  level  of  end-user  interaction. 
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3.  An  algorithm  ajiimation  system  can  be  implemented  on  a  Sun3^*^.  Sun4^^,  or 
compatible  workstation.  Since  it  is  the  workstation  of  choice  at  AFIT,  a  Sun- 
based  algorithm  animation  system  provides  the  widest  possible  local  user-base. 
Beyond  that,  Sun  provides  an  extensive  window-based  environment  for  the 
development  of  user  interfaces  in  SunView^*^  [28].  Sun  also  provides  a  variety 
of  graphics  packages  including  SunCore^^,  SunCGI^*^,  and  Sun  Pixrect  [26]. 

4.  An  algorithm  cinimation  system  can  be  developed  using  the  C  programming 
language.  Since  SunView  is  written  in  C,  and  the  Sun  operating  system, 
SunOS^^  [24],  provides  an  extensive  C  libreiry,  C  is  cin  obvious  choice  as  the 
development  language.  As  a  programming  language,  C  is  sufficiently  low-level 
to  provide  the  execution  speed  required  by  a  graphics  intensive  program,  and 
sufficiently  high-level  to  support  modern  software  engineering  principles[4:3l]. 
A  high-level  language  such  cis  Ada^*^  or  Pasczd  might  not  provide  the  necessary 
speed. 

1.6  Overview 

This  investigation  approaches  the  problem  of  developing  an  algorithm  anima¬ 
tion  system  as  a  sequence  of  logical  stages.  The  stages  are  not  discrete,  and  the 
sequence  is  not  necessarily  chronologictd.  Many  of  the  stages  overlap,  and  there  is 
considerable  feedback  between  stages. 

A  review  of  current  literature  and  software  relating  to  the  graphical  represen¬ 
tation  of  adgorithms  and  data  structures  is  conducted  with  the  goal  of  developing  a 
knowledge-baae  from  which  the  requirements  analysis  and  preliminary  design  can  be 
developed.  The  results  of  the  literature  search  are  presented  in  Section  2.3. 

In  the  rapid  prototype  stage,  several  stand-alone  sort  animations  are  imple¬ 
mented  to  help  identify  the  requirements  of  a  general  purpose  animation  system. 
The  goal  of  this  stage  is  to  enhance  the  algorithm  animation  knowledge-base  in 
preparation  for  the  requirements  analysis  and  preliminary  design  stages,  and  to  be- 
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come  familiar  with  SunOS  and  SunView  in  preparation  for  the  detailed  design  and 
implementation  stages. 

Bcised  on  the  results  of  the  literature  review  cind  rapid  prototype,  the  require¬ 
ments  for  an  algorithm  animation  system  are  defined  and  documented.  The  goal  of 
the  requirements  einalysis  is  to  determine: 

•  The  requirements  of  the  user  interface, 

•  The  requirements  of  the  programmer  interface, 

•  The  functions  and  parameters  required  to  control  the  algorithm  animation 

environment,  and 

•  The  functions  and  parameters  required  to  control  the  algorithm  animations. 

The  requirements  anailysis  discussion  cilong  with  the  enumerated  requirements 
specification  and  IDEFq  diagrams  are  presented  in  Section  2.4. 

Based  on  the  requirements  analysis,  a  design  is  developed  for  a  general-purpose 
algorithm  animation  system,  the  AFIT  Algorithm  Animation  Research  Facility 
(AAARF).  An  object-oriented  approach  is  used  for  the  preliminary  AAARF  design. 
Chapter  III  discusses  the  design  stage. 

Testing  is  conducted  on  several  levels  throughout  the  design  and  implemen¬ 
tation.  Design  testing  is  discussed  in  Section  3.2,  unit  and  integration  testing  in 
Section  4.4,  and  validation  testing  in  Section  5.3. 

With  the  rapid  prototype  as  a  starting  point  and  the  prelimin£wy  design  as 
a  development  guide,  AAARF  is  implemented  on  a  Sun4  workstation.  Structure 
charts  are  used  to  develop  the  hierarchical  structure  of  the  program  design.  The 
detailed  design  and  implementation  is  presented  in  Chapter  IV  and  detailed  in  the 
AAARF  Programmer’s  Guide  in  Appendix  D.  The  detailed  design  structure  charts 
are  presented  in  Appendix  A. 
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Documentation  is  developed  throughout  all  stages  of  the  investigation.  In  Ap¬ 
pendix  C,  the  AAARF  User’s  Manual  describes  how  to  use  the  algorithm  animation 
system.  Appendix  D  is  the  AAARF  Prograritr.iei  ’a  Guide,  it,  describes  the  algorithm 
animation  system  and  presents  a  procedure  for  creating  new  algorithm  animations. 
Appendix  E  is  the  AAARF  source  code,  fully  documented  in  accordance  with  AFIT 
System  Development  Documentation  Guidelines  and  Standards  [14].  Appendix  E  is 
included  as  a  sepeirate  volume. 

1.7  Summary 

This  chapter  described  the  problem  of  developing  a  method  to  animate  algo¬ 
rithms.  The  proposed  approach  for  solving  the  problem  considers  the  needs  of  two 
types  of  algorithm  animation  system  users;  end-users  and  client-programmers.  A 
sequence  of  development  stages  was  described  for  implementing  the  proposed  ap¬ 
proach.  The  remaining  chapters  present  the  details  of  the  approach  and  the  results 
of  the  effort. 
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II.  Requirements  Analysis  and  Specification 


2.1  Introduction 

This  chapter  presents  the  requirements  analysis  performed  on  the  problem  of 
developing  an  interactive  algorithm  animation  system.  Based  on  this  analysis,  the 
functional  requirements  for  an  interactive  algorithm  emimation  system  are  presented. 
Section  2.2  presents  information  intended  to  familiarize  readers  with  the  terms  and 
concepts  associated  with  algorithm  animation.  Previous  and  current  research  that 
has  influenced  this  study  is  reviewed  in  Section  2.3.  Section  2.4  presents  the  require¬ 
ments  analysis  discussion.  The  enumerated  requirements  specification  is  included  at 
the  end  of  the  chapter. 

2.2  Background 

A  clear  understanding  of  system  definitions  is  a  requirement  for  the  analysis  of 
any  system.  This  section  defines  the  concepts  and  terms  cissociated  with  algorithms 
and  algorithm  animation.  First,  background  information  concerning  algorithms  and 
data  structures  is  presented.  Next,  terms  and  concepts  associated  with  algorithm 
animation  cire  explained.  Information  from  this  section  is  used  throughout  the  study 
and  is  criticcd  to  an  exact  understanding  of  this  investigation. 

Data  Structures.  Data  structures  along  with  algorithms,  or  control  structures, 
are  the  basic  building  blocks  of  all  software  programs.  Data  structures  represent 
the  objects  that  programs  manipulate;  lists,  queues,  and  stacks  are  commonly-used 
data  structures.  Horowitz  and  Sahni  provide  the  following  definitions  regarding  data 
structures: 
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The  specification  of  a  data  structure  is  a.  set  of  classes  X>,  a  desig¬ 
nated  clciss  d,  a  set  of  functions  and  a  set  of  axioms  A.  The  set  of 
zucioms  describes  the  semantics  of  the  set  of  functions,  but  imply  nothing 
concerning  their  implementation.  The  triple  (T>,  !F,  A)  denotes  the  data 
structure  d,  and  is  referred  to  as  an  abstract  data  type. 

The  implementation  of  a  data  structure,  d,  is  a  mapping  from  d  to  a 
set  of  other  data  structures,  e.  This  mapping  specifies  how  every  object 
of  d  is  to  be  represented  by  the  objects  of  e.  Further,  it  requires  that 
every  function  of  d  be  implemented  using  functions  of  the  implementing 
data  structures,  e.  [16:7] 


An  array  is  amotg  the  simplest  examples  of  a  data  structure.  Informally,  an 
array  is  a  set  of  index-value  pciirs.  Figure  2.1  provides  a  more  functioned  definition 
(specification)  of  an  array.  The  set  of  cleisses,  X>,  is  {array,  index,  value}.  The 
designated  cleiss,  d,  is  array.  CREATE,  RETRIEVE,  and  STORE  establish  the  set 
of  functions,  T ,  which  are  the  fundamental  operations  for  manipulating  the  array 
data  structure.  Finally,  the  for  all  section  lists  the  set  of  eixioms.  A,  which  define 
the  operation  of  the  functions  and  provide  a  means  for  proving  the  correctness  of 
progrsuns. 


structure  ARRAY(va/ue,  index) 

declare  CREATE()  — *  array 

RETRIEVE(  array,  index)  — *  value 
STORE(  array,  index,  value)  — >  array, 
for  all  A  G  array  and  i,j  €  index  and  i  €  value  let 
RETRIEVE(CREATE,i)  ::=  error 
RETRIEVE(STORE(A,i,i),i)  ;:= 

if  EQUAL(i,j)  then  i  else  RETRIEVE(A,  j) 

end 

end  ARRAY 


Figure  2.1.  Specification  of  the  ARRAY  Data  Structure  [16:40] 
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The  abstract  data  type  (ADT)  is  introduced  here  eis  a  prelude  to  a  discussion  of 
algorithm  animation.  In  Chapter  III,  the  subject  of  ADTs  is  revisited  from  an  object- 
oriented  design  perspective.  In  object-oriented  design,  ADTs  and  their  functions  are 
referred  to  2is  objects  and  operations. 

Control  Structures.  Control  structures,  or  algorithms,  are  the  heart  of  all  soft¬ 
ware  programs.  Data  structures  represent  the  objects  that  programs  manipulate, 
and  algorithms  represent  the  methods  for  manipulating  those  objects  [3:2]. 

An  algorithm,  or  control  structure,  is  a  finite  set  of  instructions  which, 
if  followed,  accomplish  a  particular  task.  In  addition,  every  algorithm 
must  satisfy  the  following  criteria: 

1.  input:  there  are  zero  or  more  quantities  which  are  externally  sup¬ 
plied; 

2.  output:  at  least  one  quantity  is  produced; 

3.  definiteness:  each  instruction  must  be  clear  and  unambiguous; 

4.  finiteness:  if  the  instructions  of  an  algorithm  are  traced,  then  for 
cill  cases,  the  algorithm  terminates  after  a  finite  number  of  steps; 

5.  effectiveness:  every  instruction  must  be  sufficiently  basic  that  it  can, 
in  principle,  be  carried  out  by  a  person  using  only  pencil  and  paper. 

It  is  not  enough  that  each  operation  be  definite,  but  it  must  also  be 
feasible.  [16:2] 

Figure  2.2  shows  an  algorithm  for  sorting  an  array  of  integers  from  smallest 
to  largest.  The  input  to  the  cdgorithm  is  the  unsorted  array.  The  output  is  the 
sorted  array.  For  this  simple  algorithm,  it  is  obvious  that  the  criteria  of  definiteness, 
finiteness,  zmd  effectiveness  are  satisfied;  for  more  complicated  algorithms  a  formal 
proof  may  be  required  [10:7]. 
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procedure  BUBBLE_SORT(aTTay[l..nj 

integer)] 

declare 

i,j,temp  integer; 

begin 

-  initArray 

for  i  =  1  to  n  —  1 

for  j  =  n  to  i  +  1 

if  (array[j]  <  array{j  —  1]) 

-  compare 

temp  =  array[j]\ 

-  exchange 

array[j]  =  array[j  -  1]; 

- 

arraylj  —  1]  =  temp] 

- 

end  if 

end 

end 

-  inPlace 

end  BUBBLEJ50RT 

-  finished 

Figure  2.2.  BUBBLE-SORT  Algorithm 

Algorithm  Specifications.  Animating  the  execution  of  em  algorithm  involves  the 
development  of  meaningful  graphical  representations  of  the  algorithm’s  fundamental 
operations.  To  this  end,  the  idea  of  an  algorithm  specification  is  introduced.  The 
algorithm  specification  incorporates  portions  of  the  data  structure  specification  and 
the  definition  of  an  algorithm. 


The  specification  of  an  algorithm  can  be  given  by  the  quad-tuple  {D,  I,  S,  E} 
where  Z?  is  a  set  of  data  structures,  /  C  Z?  is  a  set  of  primary  data  structures, 
5  is  a  sequence  of  instructions,  and  is  a  set  of  algorithm  events. 


The  set  of  data  structures,  D,  refers  to  the  set  of  objects  manipulated  by 
the  algorithm,  with  I  corresponding  to  those  members  of  the  set  that  are  declared 
externally  and  imported  into  the  edgorithm.  For  the  algorithm  of  Figure  2.2,  the 
set  of  data  structures  consists  of  the  (integer)  array  and  (scalax)  integer  data  types. 
The  array  is  declared  externally  and  is  the  only  data  structure  (member  of  D)  of 
importance  outside  the  scope  of  the  algorithm. 
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The  set  of  algorithm  events,  or  interesting  events,  E,  consists  of  abstractions  of 
the  algorithm’s  fundamental  operations.  They  can  be  input,  output,  or  state  transi¬ 
tion  events.  Identifying  algorithm  events  is  similar  to  encapsulating  an  algorithm’s 
operations  into  procedure  calls  such  that  there  is  a  one-to-one  mapping  of  events  to 
procedures.  In  Figure  2.2,  the  algorithm  events  are  identified  zis  comments  along  the 
right  side  of  the  algorithm.  initArray  is  an  input  event,  compare,  exchange,  and 
finished  axe  state  transition  events,  and  inPlace  is  an  output  event. 

The  sequence  of  instructions,  5,  invokes  the  algorithm  events  to  accomplish 
the  algorithm’s  teisk.  The  task  is  to  transform  D  from  some  initial  state,  qi,  to  some 
final  state,  qf.  S  provides  the  transformation  by  invoking  algorithm  events. 

s 

<li  9/ 

From  an  algorithm  animation  perspective,  the  algorithm  events  and  intermedi¬ 
ate  states  are  more  interesting  than  the  fined  state  alone.  In  this  case,  S  transforms 
D  from  its  initial  state,  qi,  through  n  intermediate  states,  to  a  final  state,  g/,  by 
invoking  m  algorithm  events. 

qi^qjX  {E^  X  P") 

Animating  the  algorithm  consists  of  developing  meaningful  graphical  representations 
of  the  algorithm  events  and  intermediate  states,  E”'  x  D". 

Many  systems  have  been  developed  that  produce  graphical  representations  of 
data  structures  [19,  5],  but  such  systems  fail  to  reveal  how  the  data  is  being  pro¬ 
cessed,  and  can  present  a  confusing  or  misleading  representation  of  the  algorithm’s 
function.  For  example,  in  aji  insertion  sort,  the  algorithm  searches  a  sorted  array  for 
an  insertion  point  -  no  changes  are  made  to  the  data  structure  until  the  insertion 
point  is  found.  Only  the  insertion  is  displayed;  how  the  insertion  point  was  found 
is  not.  Algorithm  animation  can  do  more  than  simply  monitor  the  value  of  a  data 
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structure;  it  can  monitor  an  algorithm’s  fundamentid  operations  and  present  a  rep¬ 
resentation  of  the  algorithm’s  state  (E  x  D),  not  just  the  state  of  the  data  structure 
D. 


Algorithm  Animation.  In  the  few  algorithm  animation  systems  that  have  been 
developed  [6,  1,  2,  17,  23],  no  definitive  set  of  terms  has  emerged  as  a  standard,  nei¬ 
ther  has  there  been  a  standard  algorithm  animation  system  model.  This  section 
presents  the  algorithm  animation  model  used  in  this  investigation.  The  terms  in¬ 
troduced  here  are  used  consistently  throughout  this  thesis,  but  do  not  necessarily 
coincide  with  the  terms  used  in  other  algorithm  animation  systems. 

Algorithm  Animation  Components.  This  investigation  assumes  that  an 
algorithm  animation  consists  of  three  components:  an  input  generator,  an  algorithm, 
and  one  or  more  views  [6:8].  Figure  2.3  illustrates  the  utility  of  this  decomposition; 
the  individual  components  are  independent  and  can  be  modularly  replaced.  This  pro¬ 
vides  the  flexibility  required  to  support  reusable  components.  Other  decompositions 
have  been  tried  [17,  19],  but  none  are  as  flexible  emd  intuitive  as  the  input-algorithm- 
view  paradigm. 

The  components  operate  much  like  UNIX  pipes:  the  output  of  one  component 
is  the  input  to  the  next.  The  input  generator  provides  data  to  the  algorithm;  the 
data  may  be  generated  randomly,  read  from  a  file,  or  entered  by  the  user.  The 
algorithm  generates  a  stream  of  interesting  events  which  drive  the  animation  views. 
The  views  generate  the  animated  displays  of  the  algorithm’s  execution. 
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Figure  2.3.  Algorithm  Animation  Components 


Algorithm  Classes.  Algorithms  which  operate  on  identical  data  struc¬ 
tures,  and  perform  identical  functions  are  from  the  same  algorithm  class.  Using 
the  D,  I,  S,  E  algorithm  model,  algorithm  A  and  algorithm  B  are  from  the  same 
algorithm  cleiss  if  and  only  if 

Ia  =  Ib 


and 

=  ^x{h)  — ►  9/(-^x)  =  qfih) 


The  sort  class  includes  quick  sort,  heap  sort,  bubble  sort,  eind  other  sort  algorithms. 
Algorithms  from  the  same  class  generally  share  input  generators  and  views,  although 
certain  views  and  input  generators  may  be  ineffective  with  particular  algorithms.  For 
instance,  a  tree  view  is  very  effective  with  heap  sort,  but  is  of  little  use  for  any  other 
sort. 


Parameterized  Control.  User-selectable  parameters  are  associated  with 
each  component.  “Algorithm  parameters”  [6:8]  affect  some  aspect  of  how  the  algo- 
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rithm  executes.  For  example,  with  a  quick  sort  algorithm,  what  partitioning  strategy 
should  be  used?  As  the  partitions  get  smaller,  at  what  point  should  another  type  of 
sort  be  used?  “Input  Parameters”  [6:8)  affect  the  input  generator  -  what  seed  is  used 
to  generate  a  set  of  random  numbers?  How  “sorted”  is  a  set  of  unsorted  numbers? 
What  is  the  general  form  of  a  series  of  numbers?  “View  parameters”  [6:8]  affect  how 
the  animation  is  displayed  in  the  view  window.  For  example,  what  shape  is  asso¬ 
ciated  with  the  nodes  in  a  graph?  How  should  an  arbitrary  graph  be  positioned? 
Figure  2.4  shows  the  algorithm  component  structure  with  parameterized  control. 


Figure  2.4,  Parameterized  Control  of  Algorithm  Animation  Components 


Algorithm  Windows.  The  portion  of  the  workstation  designated  for  the 
display  of  an  algorithm  animation  is  called  an  algorithm  window.  Within  each  algo¬ 
rithm  window,  multiple  views  of  the  algorithm  may  be  displayed.  The  area  of  the 
algorithm  window  on  which  a  view  is  displayed  is  called  a  view  window. 
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Algorithm  Animation  System  Model.  This  section  presents  an  abstract 
model  for  an  algorithm  animation  system.  The  model  is  based  on  the  needs  of 
both  end-users  and  client-programmers,  and  incorporates  the  concepts  of  algorithm 
classes  and  components.  The  model  provides  a  concise  description  of  an  algorithm 
animation  system  and  represents  a  starting  point  for  the  requirements  analysis  and 
design  of  an  algorithm  animation  system.  The  elements  of  an  algorithm  animation 
system  are  depicted  in  Figure  2.5  and  include  the  following: 

Algorithm  Animation  Environment  Manager.  The  environment  manager  is  a 
process  with  which  end-users  interact  to  select,  control,  and  view  algorithm  ani¬ 
mations.  The  environment  manager  supports  multiple  algorithm  animations  and 
provides  a  means  for  controlling  their  execution. 

Algorithm  Animation  Component  Library.  The  component  library  is  a  col¬ 
lection  of  algorithm  animation  components  arranged  by  algorithm  class.  The  en¬ 
vironment  manager  invokes  procedures  from  the  component  library  in  response  to 
end-user  requests. 

Algorithm  Animation  Library  Manager.  The  librar>  manager  is  a  process  with 
which  client-programmers  interact  to  maintain  the  component  library.  The  library 
manager  provides  a  means  to  create  and  delete  classes  and  to  create,  modify,  or 
delete  algorithms,  input  generators,  and  views  within  algorithm  classes.  Although 
the  environment  manager  uses  the  component  library  directly,  changes  made  by  the 
library  manager  should  not  affect  the  environment  manager.  The  modified  compo¬ 
nents  should  be  immediately  ready  for  use  by  the  environment  manager. 
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End-User 

Client-Programmer 

Interface 

Interface 

Figure  2.5.  An  Algorithm  Animation  System 
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2.3  Summary  of  Current  Knowledge 


Algorithm  zmimation  is  part  of  a  lajger  body  of  research  called  program  visu¬ 
alization.  Program  visualization  refers  to  the  use  of  computer  graphics  to  illustrate 
some  aspect  of  a  program.  A  related,  but  distinctly  different  field  of  study,  visual 
programming,  refers  to  the  use  of  computer  graphics  to  develop  or  specify  a  pro¬ 
gram.  There  has  been  increased  interest  in  both  areas  of  research  recently,  as  shown 
by  the  addition  of  the  Introduction  to  Visual  Programming  (and  Program  Visualiza¬ 
tion)  Environments  course  [12]  at  the  ACM  SIGGRAPH/89  16th  Annual  Conference 
on  Computer  Graphics  and  Interactive  Techniques.  This  section  surveys  previous 
program  visualization  research  that  has  influenced  this  investigation. 

Taxonomy  of  Program  Visualization.  Brad  Meyers[20]  classifies  program  visu¬ 
alization  systems  by  whether  they  illustrate  processes  or  data,  and  whether  they  are 
static  or  dynamic.  Figure  2.6  shows  some  program  visualization  systems  and  their 
classifications. 


Static 

Dynamic 

Process 

PegaSys  [18] 

Booch  Diagrams  [4] 
Data  Flow  Diagrams 
Structure  Charts 
Flowcharts 

BALSA  [6) 

PV[51 

Data 

Incense  [19] 

Movie/Stills  [2] 

Sorting  Out  Sorting  [1] 
BALSA  [6] 

Movie/Stills  [2] 
Animation  Kit  [17] 
TANGO  [23] 

Figure  2.6.  Taxonomy  of  Prograun  Visualization  [20:15] 


2-11 


Static  displays  of  code  include  flowcharts,  data  flow  diagrams,  structure  charts, 
Booch  diagrams  [4:55],  and  other  techniques  that  attempt  to  show  data  or  control 
flow  in  a  static  graphiccd  representation  of  cin  algorithm.  The  PegaSys  system  strad¬ 
dles  the  fields  of  program  visualization  eind  visual  programming  by  providing  com¬ 
puter  graphics  to  represent  prograun  structure  and  design,  while  applying  syntax  and 
design  rules  to  determine  whether  or  not  a  program  meets  its  pictoried  documentation 
[18:72]. 

Systems  which  produce  static  displays  of  data  are  generally  designed  to  monitor 
and  display  the  value  of  program  variables.  These  systems  are  primarily  used  for 
debugging.  They  do  not  reveal  the  fundamental  operations  of  the  algorithm.  Incense 
[19]  automatically  generates  static  displays  of  data  structures.  The  displays  include 
curved  lines,  arrow  heads,  stacked  boxes,  and  user-defined  structures.  The  goal  was 
to  “make  debugging  easier  by  presenting  data  structures  to  programmers  in  a  way 
that  they  might  have  drawn  them  by  hand”  [20:18]. 

Systems  which  dynamically  display  code  typically  display  the  currently  exe¬ 
cuting  section  of  code  and  use  some  sort  of  highlighting  to  indicate  the  currently 
executing  instruction  or  instructions.  The  PV  project  at  the  Computer  Corporation 
of  America  [5]  attempted  to  use  graphics  in  all  phases  of  software  project  manage¬ 
ment  by  supporting  the  manipulation  of  static  and  dynamic  displays  of  computer 
systems,  manipulation  of  program  and  document  text,  algorithm  animation,  and 
reusable  components.  Funding  for  the  project  was  cut  just  as  the  implementation  of 
the  prototype  was  beginning  [6:31]. 

Systems  which  dynzunically  display  data  are  referred  to  as  algorithm  animation 
systems.  The  next  section  briefly  describes  the  most  significant  rese^ch  efforts  in 
this  area. 

Algorithm  Animation  Systems.  In  the  late  ’60s  and  early  ’70s,  graphics  hard¬ 
ware  was  scarce  and  expensive.  While  the  opportunity  to  use  existing  hardware  was 
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small,  its  potential  -  especially  for  educators  -  was  great.  The  obvious  solution  was 
to  record  computer-generated  images  on  film  [6:27]. 

The  first  systems  developed  explicitly  for  algorithm  animation  were  built  in 
the  mid-70’s  at  the  University  of  Toronto  by  Ron  Baecker  [6:34].  The  systems  were 
not  interactive;  the  movies  were  created  by  recording  frame  by  frame  snapshots 
of  the  executing  algorithm.  While  the  movies  were  technically  and  aesthetically 
impressive,  they  required  an  extremely  large  amount  of  time  and  effort  to  produce; 
Baecker’s  classic  algorithm  movie,  “Sorting  out  Sorting”  [1],  took  nearly  three  years 
to  make  [6:29]. 

With  the  advent  of  affordable  graphics-based  workstations,  interactive  systems 
have  replaced  movies  for  algorithm  animation.  Using  a  computer  to  do  real-time 
animation  is  now  cheaper  cind  faster  than  making  an  algorithm  movie.  Plus,  a  user 
can  interact  with  the  computer  animation,  adding  a  dimension  that  caji  never  be 
achieved  with  movies. 

Movie/Stills.  At  Bell  labs,  Bentley  and  Kernighan  developed  a  UNIX- 
based  set  of  algorithm  animation  tools  for  debugging  programs,  developing  new 
programs,  and  communicating  information  about  how  programs  work.  “The  output 
is  crude,  but  the  system  is  easy  to  use;  novice  users  can  cinimate  a  program  in 
a  couple  of  hours.  The  system  produces  movies  on  Teletype  5620  terminals  and 
Sun  workstations  and  also  renders  movies  into  ‘stills’  that  can  be  included  in  troff 
documents”  [2:abstract] 

Animation  Kit.  At  Teki-onix,  London  «uid  Duisberg  used  the  object- 
oriented  programming  language,  Smeilltalk,  to  animate  algorithms.  They  annotated 
the  algorithms  with  “interesting  events”  and  used  Smalltalk’s  Model-View-Controller 
(MVC)  system  to  notify  views  of  an  event.  They  experienced  some  problems  with 
the  MVC  system,  namely  with  incremental  updating  of  the  displays,  compositing 
multiple  views,  and  back-mapping  of  the  view  to  the  model  [17:68-71]. 
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BALSA.  The  most  powerful  and  flexible  algorithm  animation  system  to 
date  is  Brown’s  emd  Sedgewick’s  Brown  University  Algorithm  Simulator  and  Anima¬ 
tor  (BALSA)  system  [6].  BALSA,  built  in  the  early  80’s,  was  designed  to  animate,  in 
real-time,  any  and  all  algorithms.  It  is  best  described  as  bringing  the  movie  Sorting 
out  Sorting  to  life  [6:39].  In  his  dissertation  [6]  and  in  several  journal  articles  [7,  8,  9], 
Brown  describes  how  BALSA  was  implemented,  outlines  the  general  methods  of  al¬ 
gorithm  animation,  and  gives  examples  of  BALSA  animations.  Brown’s  dissertation 
presents  a  thorough  and  informative  history  of  algorithm  emimation  and  provides 
detailed  descriptions  of  most  of  the  systems  mentioned  here. 

TANGO.  John  Stasko’s  Transition-based  ANimation  Generation 
(TANGO)  system  [23]  introduced  a  design  methodology  for  simplifying  the  creation 
of  algorithm  animation.  TANGO  provides  the  client-prcgrcimmer  a  small  but  pow¬ 
erful  set  of  primitive  animation  commands.  The  primitives  provide  a  consistent 
animation  design  interface,  independent  of  the  underlying  hardware  and  software. 
Stasko’s  work  is  significant  in  that  it  advances  the  accessibility  of  algorithm  anima¬ 
tion  cind  provides  a  means  for  creating  cinimations  that  exhibit  smooth  continuous 
movement. 

Applications.  One  of  the  first  uses  for  algorithm  emimation  was  education  - 
teaching  the  concepts  of  control  emd  data  structures.  Baecker’s  algorithm  movies  emd 
Brown’s  BALSA  system  had  education  as  their  primeu’y  goed.  At  Brown  University, 
courses  in  programming,  algorithms,  data  structures,  and  mathematics  have  been 
taught  successfully  with  BALSA  [9:29j.  “. . .  Instructors  in  the  courses  were  able  to 
cover  material  at  a  much  accelerated  rate  (estimated  at  30%  faster)  . . .  Unfortunately, 
no  controlled  experiments  could  be  done  . . . ,  the  introduction  of  the  lab  coincided 
with  the  introduction  of  a  new  text  ...”  [6:170]. 

Another  application  area  is  algorithm  research  and  development.  A  BALSA 
animation  of  Knuth’s  dynamic  Huffman  trees  revealed  strange  behavior  with  a  par- 
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ticular  set  of  input.  Eventually  a  new,  improved  edgorithm  for  dynamic  Huffman 
trees  was  developed.  Likewise,  new  versions  of  shell  sort  and  merge  sort  have  been 
developed  on  the  BALSA  system  [6:5]. 

System  debugging  and  performance  monitoring  is  another  area  in  which  al¬ 
gorithm  animation  can  be  useful.  Nearly  all  program  visualization  systems  which 
produce  static  displays  of  program  data  are  used  for  debugging  or  performance  mon¬ 
itoring.  Algorithm  animation  systems  can  perform  the  Scime  function.  However,  for 
monitoring  data,  systems  that  produce  static  representations  may  be  more  efficient; 
they  can  typically  generate  graphic<d  displays  of  data  automatically  based  on  the 
data  type,  with  little  or  no  assistance  from  the  end-users.  Brown  discusses  systems 
programming,  but  admits  that  before  BALSA  can  be  useful,  it  must  provide  some 
method  for  automatically  creating  graphical  representations  [9:29]. 

2.4  Requirements 

This  section  presents  the  requirements  analysis  for  an  interactive  algorithm 
animation  system.  Using  algorithm  animation  system  model  (Figure  2.5)  as  a  start¬ 
ing  point,  the  analysis  is  conducted  from  two  points  of  view:  the  end-user  and  the 
client-programmer. 

Specification  Technique.  Bcised  on  the  results  of  the  literature  review  and  the 
rapid  prototype,  the  enumerated  requirements  specification  was  compiled.  The  Air 
Force  Materials  Lab’s  IDEFo  structured  analysis  lemguage  was  used  to  document  the 
high-level  requirements  analysis.  IDEFo  is  a  version  of  SofTech’s  Structured  Aneilysis 
and  Design  Technique  (SADT)  used  by  the  Air  Force  and  other  DoD  agencies  [14]. 
IDEFo  is  described  briefly  here.  The  high-level  IDEFo  documents  for  the  analysis 
are  included  at  the  end  of  this  section. 

The  idea  behind  structured  analysis  is  to  reduce  the  complexity  of  a  problem 
by  hierarchically  decomposing  the  problem  into  pieces  that  can  be  more  easily  un- 
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derstood.  The  decomposition  Cein  be  based  on  data  or  processes;  IDEFo  is  based 
on  the  anedysis  of  processes  or  activities.  The  decomposition  is  reflected  through 
a  series  of  function  diagrams^  and  further  documented  through  the  use  of  a  facing 
page  text  for  each  diagram.  Each  functional  diagram  illustrates  one  level  of  the  de¬ 
composition.  Figure  2.7  shows  the  highest-level  IDEFo  diagram  for  the  algorithm 
animation  system.  The  facing  page  text  provides  additional  information  that  is  not 
easily  inferred  from  the  diagram.  Data  dictionary  entries  provide  even  more  detailed 
information  regarding  each  activity  and  data  item  [13:4-5]. 

The  primary  object  of  decomposition  in  IDEFo  is  a  process,  or  activity;  for 
example,  Manage  Algorithm  Animation  System  in  Figure  2.7.  An  activity  is  repre¬ 
sented  by  a  rectangular  box  on  the  function  diagram.  The  activity  name  and  number 
appear  in  the  box.  The  activity  number  provides  a  meams  for  tracing  through  the 
hierarchical  decomposition. 

Interfaces  between  activities  are  represented  by  arrows  entering  or  leaving  ac¬ 
tivity  boxes.  The  arrows  represent  data  produced  by  or  needed  by  a  activity.  The 
type  of  interface  is  reflected  by  the  position  of  the  arrow  with  respect  to  the  box: 
input  arrows  enter  the  left  side  of  the  activity  box,  output  eirrows  leave  the  right  side 
of  the  box,  control  arrows  enter  the  top  of  the  box,  and  mechanism  arrows  either 
enter  or  leave  the  bottom  of  the  box.  The  activity  is  viewed  as  transforming  its 
inputs  into  outputs  under  the  guidmce  of  its  controls.  Control  and  output  arrows 
£ire  required  for  every  activity;  input  and  mechcinism  arrows  are  optional. 

End-User  Requirements.  The  end-user  of  the  algorithm  animation  system 
should  be  able  to  customize  the  animation  environment.  Multiple  algorithm  win¬ 
dows,  with  multiple  views  of  the  algorithm  in  execution  should  be  possible.  The  user 
should  control  the  position  and  size  of  eilgorithm  windows  and  views.  As  appropriate, 
the  user  should  be  able  to  zoom  in  on  interesting  aspects  of  an  animation  and  pan 
through  the  animation.  The  user  can  close  algorithm  windows  at  any  time.  Likewise 
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Figure  2.7.  Top-Level  IDEFq  Diagram  for  an  Algorithm  Animation  System 


an  algorithm  window’s  contents  may  be  replaced  at  any  time.  The  emimation  system 
may  be  exited  at  any  time. 

For  each  algorithm  window,  the  user  must  select  an  algorithm  clciss;  that  is 
sorts,  tree  searches,  differential  equations,  etc.  Within  an  algorithm  claiss,  the  user 
may  select  one  of  several  possible  algorithms.  For  each  algorithm,  one  or  more  views 
may  be  selected  which  are  appropriate  for  algorithms  of  that  class.  Likewise,  an 
input  generator  is  selected.  The  user  may  modify  algorithm,  input  generator,  and 
view  parameters. 

The  user  may  control  each  animation  window  individually  or  control  all  win¬ 
dows  simultaneously.  In  either  case,  controls  available  to  the  user  are:  start  or  con- 
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tinue  an  animation,  restart  or  reset  an  animation,  pause  or  terminate  the  animation, 
single-step  the  animation,  control  the  speed  of  the  animation,  and  set  break-points 
for  pausing  the  animation.  Break-point  setting  and  single-stepping  are  beised  on 
an  algorithm’s  interesting  events.  Since  algorithms  from  different  clcisses  may  be 
controlled  simultaneously  -  neither  break  points  nor  single-stepping  are  required 
mechanisms  for  simultaneous  control. 

Some  algorithms  cannot  execute  quickly  enough  to  provide  an  interesting  real¬ 
time  animation.  For  this  type  of  algorithm,  the  user  needs  am  animation  recorder. 
Within  an  algorithm  window,  the  animation  recorder  is  used  as  a  video  tape  recorder. 
Animations  may  be  recorded  either  on-line  or  off-line  and  played  back  later.  The 
animation  may  be  viewed  at  any  speed  in  forward  or  reverse. 

Algorithm  windows  must  provide  a  mechanism  for  monitoring  and  modifying 
the  input  parameters,  control  parameters,  algorithm  parameters,  and  view  param¬ 
eters.  In  addition  to  the  view  windows,  every  algorithm  window  should  support  a 
status  display  which  presents  statistics  describing  the  current  state  of  the  algorithm. 
The  user  should  be  able  to  interrogate  a  particular  aspect  of  the  animation  and  have 
the  results  of  the  interrogation  displayed. 

The  animation  environment  is  very  flexible;  there  are  many  user-selectable 
options  -  position,  size,  and  number  of  algorithm  and  view  windows,  algorithms, 
input  generators,  views,  and  parameters.  There  must  be  a  way  for  the  user  to 
save  and  restore  a  particular  environment,  where  the  environment  includes  all  user- 
selectable  options  available  at  a  particular  time. 

To  help  users  understand  all  the  options  available,  on-line  help  should  be  avail¬ 
able  for  every  interactive  function. 

Client-Programmer  Requirements.  A  well-defined,  consistent  programmer  in¬ 
terface  is  essenticil  to  the  effectiveness  of  ein  algorithm  animation  system.  If  new 
algorithms,  views,  and  input  generators  cannot  easily  be  added  to  the  system,  the 
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system  cannot  fulfill  its  purpose.  The  client-programmer  should  be  able  to  create, 
modify,  and  delete  classes  within  the  algorithm  animation  system;  and  to  create, 
modify,  and  delete  algorithms,  input  generators,  and  views  within  algorithm  classes. 
There  should  be  some  sort  of  automatic  vcdidation  of  new  and  modified  algorithm 
animations;  for  example,  insuring  that  the  interface  to  the  animation  system  is  cor¬ 
rect,  that  the  interfaces  between  modules  within  a  class  tire  correct,  and  that  there 
are  no  naming  ambiguities. 

The  system  should  provide  a  library  of  functions  common  to  all  algorithm  an¬ 
imations  as  well  as  a  library  of  primitives  to  support  color  animation.  The  system 
should  be  structured  such  that  the  algorithm  animations  are  independent  and  sep¬ 
arate  from  the  main  animation  controller.  Individual  algorithm  animations  can  be 
added,  deleted,  and  modified  from  the  algorithm  animation  system  with  no  effect 
on  other  algorithm  animations  or  the  system  as  a  whole.  Likewise,  as  long  as  the 
interface  to  the  algorithm  animations  is  not  modified,  the  maun  algorithm  animation 
controller  can  be  modified  without  affecting  the  algorithm  animations. 

2. 5  Summary 

This  chapter  presented  the  requirements  analysis  for  the  development  of  an  al¬ 
gorithm  animation  system.  Section  2.2  discussed  the  terms  and  concepts  associated 
with  data  structures,  algorithms,  and  algorithm  animation.  The  algorithm  anima¬ 
tion  system  model'^d  the  concept  of  an  algorithm  specification  were  presented. 
Section  2.3  presented  the  results  of  a  review  of  literature  relating  to  algorithm  ani¬ 
mation  and  progreim  visualization.  Based  on  the  literature  review  the  details  of  the 
requirements  analysis  were  presented  in  Section  2.4.  The  remainder  of  this  chapter 
presents  the  high-level  IDEFo  diagrams  (Figure  2.8  to  Figure  2.12)and  the  enumer¬ 
ated  requirements  specification  (Figure  2.13  to  Figure  2.15). 

The  next  three  chapters  use  the  requirements  developed  in  this  chapter  as  the 
basis  for  designing,  implementing,  and  testing  an  algorithm  animation  system. 
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NODE:  AO  TITLE:  Mjmage  Algorithm  Animation  System 


Figure  2.8.  IDEFo  AO  Diagram  -  Manage  Algorithm  Animation  System 
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NODE:  A1  TITLE:  Manage  Algorithm  Animations 

Figure  2.9.  IDEFo  A1  Diagram  -  Manage  Algorithm  Animations 
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Figure  2.10.  IDEFo  A14  Diagram  -  Modify  Algorithm  Class 
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End-User  Input  Algorithm  Animations 


NODE:  A2  TITLE:  Manage  Animation  Environment 


Figure  2.11.  IDEFq  A2  Diagram  -  Manage  Algorithm  Environment 


NODE:  A22  TITLE:  Manage  Algorithm  Window 

Figure  2.12.  IDEFq  A22  Diagram  -  Manage  Algorithm  Window 
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1.0  Establish  a  user  interface  to  the  algorithm  animation  environment 
manager 

1.1  Allow  user  to  customize  the  algorithm  amimation  environment 

1.11  Provide  multiple  algorithm  windows 

1.12  Provide  multiple  view  windows  within  each  algorithm  window 

1.13  Allow  user  to  position  and  size  algorithm  and  view  windows 
as  desired 

1.14  Allow  user  to  zoom  and  pan  display  in  view  windows  at  any 
time 

1.15  Terminate  animation  session  at  any  time 

1.2  Allow  user  to  select  algorithms,  inputs,  and  views  for  each  algo¬ 
rithm  window 

1.21  Select  algorithm  class  from  a  list  of  available  classes 

1.22  Select  algorithms  for  animation  from  a  list  of  available  algo¬ 
rithms  within  a  selected  class 

1.23  Specify  control  parameters  for  an  algorithm  from  a  list  of 
control  parameters  associated  with  a  selected  algorithm 

1.24  Specify  input  parameters  for  an  algorithm  from  a  list  of  input 
parameters  associated  with  a  selected  class 

1.25  Select  views  parameters  for  an  algorithm  from  a  list  of  views 
associated  parameters  with  a  selected  class 

1.26  Close  animation  window  at  any  time 


Figure  2.13.  Enumerated  Requirements  for  Algorithm  Animation  System  (1  of  3) 
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1.3  Allow  user  to  control  execution  of  algorithm  animations 

1.31  Select  control  mode:  individual,  simultaneous 

1.32  Begin  (reset)  an  animation 

1.33  Control  speed  of  animation 

1.34  Terminate  (pause)  animation  at  any  time 

1.35  Restart  a  paused  (terminated)  animation 

1.36  Run  animation  in  single-step  mode 

1.37  Set  break-point  for  pausing  animation;  based  on  algorithm 
events  for  the  particulair  algorithm 

1.4  Provide  a  central  control  mode 

1.5  Provide  an  animation  recorder  mode 

1.51  Start  recording  all  algorithm  interesting  events  generated  by 
an  animation  within  a  view  window 

1.52  Stop  animation  recording 
1.5.3  Save  animation  recording 

1.54  Load  animation  recording 

1.55  Play  animation  recording  forward  or  backward  at  any  speed 

1.56  Provide  option  to  turn  oiF  display  during  recording  session 

1.57  Provide  option  to  record  animation  off-line 

1.6  Provide  environment  save  and  restore  function 

1.61  Save  all  user  selections  currently  in  effect 

1.62  Restore  previously  saved  environment  (overrides  current  en¬ 
vironment) 

1.7  Provide  on-line  help  for  every  interactive  function 


Figure  2.14.  Enumerated  Requirements  for  Algorithm  Animation  System  (2  of  3) 
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2.0  Establish  a  programmer  interface  to  the  algorithm  animation  library 

2.1  Allow  programmer  to  create,  modify,  and  delete  algorithm  ani¬ 
mations  within  the  algorithm  animation  system 

2.11  Create,  modify,  and  delete  algorithms 

2.12  Create,  modify,  and  delete  algorithm  views 

2.13  Create,  modify,  and  delete  algorithm  input  generators 

2.2  Provide  automatic  validation  of  chcinges  to  algorithm  animation 
system 

2.21  Interface  errors  are  reported  immediately 

2.22  Protect  algorithm  animation  system  from  accidentad  corrup¬ 
tion  during  development  of  new  algorithm  animations 

2.3  Provide  library  of  primitive  functions  to  support  color  animation. 

2.4  Provide  library  of  functions  common  to  all  algorithm  animations. 

2.5  An  individual  dgorithm  claas  can  be  developed  or  modified  with¬ 
out  any  effect  on  other  algorithm  classes  or  the  algorithm  anima¬ 
tion  system  as  a  whole. 

Figure  2.15.  Enumerated  Requirements  for  Algorithm  Animation  System  (3  of  3) 
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III.  System  Design 


S.  1  Introduction 

This  chapter  presents  a  prelimin£iry  software  design  for  an  algorithm  £mimation 
system  -  The  AFIT  Algorithm  Animation  Research  Facility  (AAARF).  Throughout 
the  remainder  of  the  investigation,  AAARF  refers  to  this  peirticular  design  and  im¬ 
plementation  of  an  algorithm  animation  system.  Prelimin£tfy  design  is  concerned 
with  the  transformation  of  requirements  into  a  software  architecture.  Chapter  IV 
presents  the  detailed  design  which  focuses  on  refinements  of  the  architectural  rep¬ 
resentation  leading  to  detailed  data  structures  and  algorithmic  representations  for 
implementation  [21:215]. 

An  object-oriented  design  methodology  was  used  to  translate  the  requirements 
into  high-level  objects  and  operations.  An  object-oriented  approach  was  particularly 
well-suited  because  an  algorithm  animation  system  consists  of  individual  elements 
(objects)  with  which  end-users  and  client-programmers  interact;  data  flow  is  at  best 
a  side  issue.  This  chapter  describes  the  test  methodology,  the  object-oriented  design 
technique,  and  the  AAARF  high-level  objects. 

3.2  Test  Methodology 

Two  commonly  used  software  testing  approaches  are  “black  box”  and  “white 
box”  testing  [21:470].  These  are  generic  classifications;  within  each  category  there 
axe  several  specific  testing  methods. 
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Black  box  testing  methods  focus  on  the  functional  requirements  of  the  software. 
These  methods  attempt  to  find  errors  in  the  following  categories; 

1.  Incorrect  or  missing  functions, 

2.  Interface  errors, 

3.  Errors  in  data  structures, 

4.  Performance  errors,  and 

5.  Initialization  zind  termination  errors  [21:484]. 

White  box  testing  methods  axe  based  on  the  close  examination  of  procedural 
detail.  They  strive  to 

1.  Exercise  all  independent  paths  within  a  module  at  least  once, 

2.  Exercise  all  logicad  decision  for  both  the  TRUE  and  FALSE  cases, 

3.  Execute  all  loops  at  their  boundaries  and  within  their  operational  bounds,  and 

4.  Exercise  all  data  structures  to  assure  their  validity  [2T.472]. 

No  white  box  testing  is  possible  at  this  point  in  the  design;  it  is  deferred  until 
the  detailed  design  and  implementation  phase.  However,  some  black  box  testing  is 
possible.  Basically  the  requirements  specification  is  compared  to  the  objects  and 
operations  defined  in  the  design  to  insure  that  all  requirements  are  met.  The  ob¬ 
ject  interfaces  and  data  structures  are  also  inspected.  Further  black  box  testing  is 
conducted  during  the  det^uled  design  and  implementation  stage  (Chapter  IV). 

S.3  Object-Oriented  Design 

Object-oriented  design  (OOD)  is  a  relatively  new  design  concept  that  has 
evolved  over  the  pzist  15  years  [21:335].  OOD  builds  upon  four  important  soft¬ 
ware  design  concepts:  abstraction,  information  hiding,  reusability,  and  modularity. 
This  section  discusses  the  terms  and  procedures  associated  with  OOD. 


Figure  3.1.  Mapping  a  Reed  World  Object  into  the  Software  Domain  [21:337] 

Objects,  Operations,  and  Messages.  An  object  is  an  abstract  data  type  (Sec¬ 
tion  2.2)  that  represents  a  real  world  entity  in  the  software  domeiin  (Figure  3.1).  An 
object  consists  of  a  private  part  and  a  public  part. 

The  private  part  consists  of  the  underlying  data  structure  that  represents  the 
object’s  state  and  a  set  of  operations,  or  methods,  for  manipulating  the  data  structure. 
The  public  part  is  the  object’s  interface  to  the  rest  of  the  software  system;  it  consists 
of  messages  which  specify  what  operation  is  to  be  performed  on  the  object,  but  not 
how  the  operation  is  to  be  performed  [21:336]. 

Defining  a  private  part  and  providing  messages  to  invoke  appropriate  process¬ 
ing  achieves  information  hiding  -  the  details  of  implementation  are  hidden  from  all 
program  elements  outside  the  object.  Objects  and  their  operations  provide  inher¬ 
ent  modularity  -  software  elements  (objects  and  operations)  are  grouped  with  a 
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Figure  3.2.  Objects  of  the  Class  Books  [21:338] 


well-defined  interface  (messages)  to  the  rest  of  the  software  system  [21:336]. 

Classes,  Instances,  and  Inheritance.  A  class  is  a  set  of  objects  that  have  the 
same  or  similar  characteristics  and  perform  the  same  or  similar  operations.  An  object 
is  an  instance  of  a  larger  clciss  [21:338].  All  objects  are  members  of  a  class  and  inherit 
the  private  part  of  the  clciss. 

For  example  in  Figure  3.2,  the  object  Dictionary  is  an  instance  of  the  larger 
class  Books  and  inherits  the  operations  open,  close,  and  mark.  Books  is  a  data 
abstraction  that  makes  creating  new  instances  a  simple  matter  [21:338]. 
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The  software  engineering  goal  of  reusability  is  achieved  by  creating  objects 
that  build  on  existing  attributes  and  operations  inherited  from  the  class.  Only  the 
new  object’s  differences  from  the  class  must  be  specified,  rather  than  defining  all  the 
characteristics  of  the  new  object  [21:338]. 

Object-Oriented  Design  Method.  Booch  suggests  the  following  procedure  for 

OOD: 


•  Identify  the  Objects.  Establish  classes,  objects,  zmd  instances. 

•  Identify  the  Operations.  Determine  the  operations  that  may  be 
meaningfully  performed  on  the  objects  or  by  the  objects. 

•  Establish  the  Visibility.  Determine  relationships  between  objects; 
what  other  objects  aje  seen  by  a  given  object. 

•  Establish  the  Interface.  Establish  object  interfaces  (messages).  The 
interface  forms  the  boundary  between  the  outside  (public)  view  and 
the  inside  (private)  view  of  the  object. 

•  Implement  Each  Object.  Choose  a  suitable  representation  and  im¬ 
plement  the  interface.  [4:48-49] 

5-4  High-Level  AAARF  Design 

This  section  presents  a  high-level  OOD  design  for  AAARF.  Two  high-level 
graphical  object  classes  and  an  edgorithm  component  object  class  were  defined  for 
the  design.  The  names  and  operations  of  the  two  graphical  object  classes  coin¬ 
cidentally  map  almost  directly  to  objects  provided  by  SunView.  At  this  level  of 
design  the  correspondence  is  of  no  consequence,  but  during  the  detailed  design  and 
implementation  phase  the  coincidence  proves  to  be  very  convenient. 

In  this  section,  the  high-level  object  cleisses  and  their  interfaces  are  defined. 
Specific  object  instances  and  their  relationships  are  also  described.  The  abstract 
data  type  (ADT)  specification  notation  of  Figure  2.1  is  used  to  define  the  AAARF 
objects.  The  axioms  are  omitted;  they  are  used  primarily  for  proving  the  correctness 
of  a  process  and  that  is  beyond  the  scope  of  this  study. 
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The  window  Object  Class.  A  window  is  an  abstraction  that  represents  a  rect¬ 
angular  region  of  the  workstation  display.  Text  or  graphics  can  be  displayed  in  a 
window,  windows  can  be  displayed  within  other  windows,  windows  cein  be  moved 
and  resized.  As  shown  later  in  this  section,  certain  types  (instantiations)  of  windows 
may  limit  the  basic  window  attributes.  Figure  3.3  lists  the  ADT  specification  for  the 
window  object  class. 

structure  window(Pos,  Size,  Text,  Graphics) 
declare  create()  window 

show(window)  window 
hide(window)  — >  window 
destroy(window)  — >  window 
setPosition(window,  Pos)  — »  window 
getPosition(window)  — >  Pos 
setSize(window,  Size)  window 
getSize(window)  — >  Size 
putText( window,  Text)  — >  window 
putGraphics(window,  Graphics)  — >  window 

end 

end  window 

Figure  3.3.  Specification  for  AAARF  window  Object 

AAARF  Window  Hierarchy.  The  AAARF  design  incorporates  three  lev¬ 
els  of  windows  to  provide  the  user  with  multiple  simultaneous  algorithm  animations 
and  multiple  views  of  each  animation.  Figure  3.4  shows  the  insteinces  of  window  used 
by  AAARF  and  their  relationship  to  one  another. 

Main  Window.  This  is  a  window  within  which  all  interaction  with  AAARF  is 
contained.  The  main  window  supports  multiple  instances  of  algorithm  windows.  No 
a.umation  actually  taices  place  in  the  main  window;  it  serves  as  a  high-level  manager 
of  the  animation  environment. 
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Algorithm  Window,  Like  the  main  window,  eilgorithm  windows  exist  mainly 
to  contain  other  windows.  Every  algorithm  window  is  associated  with  a  particular 
algorithm  clciss.  Algorithm  windows  may  be  created  and  destroyed  at  any  time,  but 
there  is  limit  to  the  number  that  can  exist  at  ainy  given  time  (an  implementation 
detail).  Each  algorithm  window  supports  multiple  instances  of  view  windows.  Al¬ 
gorithm  windows  can  be  resized  and  moved  cinywhere  on  an  AAARF  main  window, 
and  they  may  overlap  one  another. 

View  Window.  Animations  are  displayed  in  view  windows.  Every  view  window 
is  associated  with  a  particular  view  of  cin  algorithm.  At  lecist  one  view  window  is 
active  within  every  algorithm  window  (the  maximum  is  left  as  an  implementation 
issue).  View  windows  can  be  resized  and  moved,  but  they  cannot  extend  beyond 
their  algorithm  window,  and  they  may  not  overlap.  This  forces  a  modular  animation 
environment  and  minimizes  the  end-user’s  opportunity  to  “loose”  windows. 

The  pzinel  Subclass.  The  panel  is  a  subclass  of  window,  pemels  provide 
a  means  for  the  end-user  to  monitor  and  modify  system  parameters,  panels  cannot 
be  resized,  but  retain  all  other  characteristics  of  the  window  class.  The  basic  window 
operations  are  supplemented  with  operations  to  manipulate  low-level  panel  Item 
objects  which  provide  the  interface  to  the  user,  panelltems  can  be  associated  with 
particular  action  operations  which  are  invoked  in  response  to  a  pzmelltem  state 
change. 

One  set  of  panel  objects  is  associated  with  the  main  window  and  another  with 
each  instance  of  algorithm  -window.  Figure  3.6  and  Figure  3.9  show  the  relationship 
between  windows  and  their  panels. 

•  Main  window  panels 

-  Environment  Panel.  The  environment  panel  is  used  to  save,  restore,  and 
delete  animation  environments. 
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Figure  3.4.  Instances  of  window 


-  Control  Panel.  The  control  panel  is  used  to  impose  simultaneous  control 
on  all  active  cilgorithm  windows. 

•  Algorithm  window  panels 

-  Master  Control  Panel.  The  master  control  panel  provides  a  way  for  the 
user  to  modify  the  input,  view,  algorithm,  and  control  parameters  for  an 
animation. 

-  Recorder  Panel.  The  recorder  panel  allows  the  user  to  record  and  playback 
animation  recordings;  and  to  save,  load,  and  delete  recordings. 
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—  Status  Panel.  The  status  panel  provides  the  user  with  information  regard¬ 
ing  the  current  state  of  the  animation  or  some  particular  aspect  of  the 
animation. 

The  menu  Object  Class.  The  menu  provides  a  method  for  the  user  to  make  a 
selection  from  several  options,  menus  consist  of  low-level  objects  called  menultems. 
menultems  can  be  associated  with  a  particular  operation  which  is  invoked  when  the 


menultem  is  selected.  Figure  3.5  describes  the  menu  class  operations. 


structure  menu(Pos,  noltems,  menultem,  itemNo,  Selection) 

declare 

create()  — ►  menu 
show(menu)  — >  menu 
hide(menu)  — ►  menu 
destroy(menu)  —>■  menu 
getSelection(menu)  —y  Selection 
setPosition(menu,  Pos)  — >  menu 
setMenuItem(menu,  menultem)  — ♦  menu 
getMenuItem(menu,  menultem)  — »  itemNo 
deleteMenuItem(menu,  menultem)  — +  menu 
getNoItems(menu)  — ♦  noltems 

end 

end  menu 

Figure  3.5.  Specification  for  AAARF  menu  Object 

The  AAARF  design  uses  two  instances  of  menu  to  provide  the  user  with  high- 
level  decisions  on  two  levels. 

Main  Menu.  This  menu  is  used  to  select  a  new  algorithm  animation  and  to 
activate  panels  for  simultaneous  control  of  animations  and  for  saving  and  restoring 
animation  environments. 

Algorithm  Window  Menu.  An  algorithm  window  menu  is  associated  with  every 
algorithm  window.  This  menu  is  used  to  activate  various  panels  which  control  the 
animation,  record  the  animation,  and  present  a  status  display  for  the  animation. 
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Figure  3.6.  Structure  of  the  Main  Window 
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The  component  Object  Class.  The  component  object  provides  a  means  to  select 
and  control  the  algorithm  components  depicted  in  Figure  2.4.  The  component  objects 
are  associated  with  algorithm  windows  and  view  windows,  but  not  with  the  main 
window.  Figure  3.7  show  the  operations  associated  with  the  component  object  class. 


structure  component(componentName,  Parameter,  Value) 

declare  set(component,componentName)  — +  component 
get(component)  — >  componentName 

setParameter(component,  Parameter,  Value)  — ♦  component 
getParameter(component,  Parameter)  — >  Value 

end 

end  window 


Figure  3.7.  Specification  for  AAARF  component  Object 

The  AAARF  design  uses  three  types  of  components:  input,  algorithm,  and 
view.  Each  type  supplements  the  basic  operations  supplied  by  the  class  with  a  set  of 
component-specific  operations.  Figure  3.8  shows  the  additional  operations  for  each 
type  of  component  object.  Figure  3.9  illustrates  how  the  components  fit  into  the 
algorithm  window  structure. 


Object;  input  component 
getlnput(dataStructure) 

Object:  algorithm  component 
getlE(interestingEventStructure) 
execute  Algorithm( ) 

Object:  view  component 

processIE(interestingEventStructure,  viewParameters) 

iipdateView(viewParameters) 

paint  View(viewParameters) 


Figure  3.8.  Supplemental  Operations  for  AAARF  component  Objects 
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Figure  3.9.  Structure  of  Algorithm  Windows 


3.5  Summary 

This  chapter  described  the  object-oriented  design  technique,  the  design  ob¬ 
jects  and  operations,  and  the  test  methodology  for  the  design.  In  the  next  chapter, 
the  preliminary  design  is  translated  into  the  detailed  design  and  implementation  of 
AAARF. 
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IV.  Detailed  Design  and  Implementation 


4.1  Introduction 

This  chapter  discusses  the  detailed  design  and  implementation  of  an  algorithm 
animation  system  on  a  Sun4  workstation  using  the  SunView  window-based  user  in¬ 
terface  environment.  This  particular  implementation  is  called  the  AFIT  Algorithm 
Animation  Research  Facility  (AAARF)  and  is  based  on  the  preliminary  design  de¬ 
veloped  in  Chapter  III.  As  with  any  design  implementation,  this  is  just  one  of  many 
possible  realizations. 

The  topics  discussed  in  this  chapter  include:  the  detailed  design  methodol¬ 
ogy,  the  implementation  approach,  the  testing  methodology,  SunView,  and  major 
implementation  decisions.  Appendix  A  and  The  AAARF  Programmer’s  Guide  in 
Appendix  D  provide  additional  details  of  the  implementation.  For  even  finer  detail, 
see  the  AAARF  source  code  in  Appendix  E;  it  is  included  as  Volume  2. 

4.2  Detailed  Design  Methodology 

The  preliminary  design  (Chapter  III)  provided  an  object-oriented  architec¬ 
tural  representation  for  AAARF.  Operations,  interfaces,  and  data  structures  were 
defined  for  the  objects  that  comprise  the  AAARF  design.  The  detailed  design  is 
concerned  with  developing  an  algorithmic  abstraction  for  coordinating  the  activities 
of  the  AAARF  objects.  In  this  stage  of  design,  the  preliminary  design  objects  and 
operations  are  used  to  develop  a  high-level  procedural  description  of  the  software. 

Structure  charts  are  used  to  represent  the  (hiereirchical)  procedural  structure  of 
the  AAARF  program  modules.  Structure  charts  are  am  effective  program  structure 
notation,  yet  simple  enough  that  practically  anyone  can  understand  them  with  little 
or  no  explanation.  Other  program  structure  notations,  such  as  Wau-nier-Orr  and 
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Jackson  diagrams,  could  be  used  with  equal  effectiveness  [21:210].  Appendix  A 
contains  the  structure  charts  for  the  AAARF  implementation. 

4-3  Implementation  Approach 

Typically,  the  first  step  in  the  implementation  stage  is  determining  the  tar¬ 
get  system,  the  programming  language,  and  the  system  tools  for  implementing  a 
particular  design.  Leaving  these  decisions  until  the  implementation  phcise  prohibits 
characteristics  of  a  programming  language  or  the  target  hardware  architecture  from 
influencing  the  software  design  and  data  structures. 

In  this  investigation,  it  was  determined  from  the  outset  that  AAARF  would 
execute  on  Sun  workstations.  During  the  course  of  the  design  development,  the 
SunView  window-based  environment  was  selected  as  the  basis  of  the  AAARF  im¬ 
plementation;  SunView  provides  nearly  all  the  graphiccil  objects  specified  in  the 
AAARF  preliminary  design.  SunView  is  described  in  Section  4.5.  C  was  selected 
as  the  programming  language.  It  provides  the  speed  required  for  computer  graphics 
intensive  applications,  and  supports  modern  software  engineering  concepts.  The  Sun 
workstation  operating  system,  SunOS,  and  SunView  provide  an  excellent  interface 
to  C. 

Having  selected  the  programming  language,  target  machine,  and  program  de¬ 
velopment  tools,  the  AAARF  detailed  design  modules  (Section  4.2)  are  mapped  to 
program  modules.  Many  of  the  AAARF  objects  map  directly  to  SunView  objects, 
significantly  simplifying  the  implementation.  Several  important  implementation  de¬ 
cisions  are  made:  how  to  handle  multiple  algorithms  and  views,  how  to  link  algo¬ 
rithm  classes  to  the  mciin  algorithm  animation  system,  and  how  to  help  the  client- 
programmer  develop  new  animations.  The  highlights  of  this  step  are  described  in 
Section  4.6.  Finally,  the  implementation  is  tested  m  described  in  Section  4.4. 
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4-4  Implementation  Testing 

Implementation  testing  is  conducted  on  three  levels:  unit  testing,  integration 
testing,  and  validation  testing  [21:502].  These  are  the  white  box  testing  methods 
mentioned  in  Section  3.2.  Unit  testing  is  applied  to  individual  functions  as  they 
are  developed.  After  unit  testing,  integration  testing  is  performed  on  the  complete 
program  to  ensure  the  interfaces  between  functions  are  correct.  Finally,  validation 
testing  is  performed  to  provide  final  assurance  that  the  program  meets  the  stated 
requirements. 

In  this  study,  the  detailed  design  is  implemented  using  a  top-down  integration 
approach  [21:507].  The  high-level  module  interfaces  are  developed  first;  stubs  are 
used  to  exercise  the  function  interfaces.  Most  stubs  do  little  or  no  data  manipulation. 
As  stubs  develop  into  bona  fide  procedures,  unit  testing  is  performed.  Integration 
and  unit  testing  are  conducted  repeatedly  throughout  the  development  process. 

Validation  testing  is  the  continuation  of  the  black  box  testing  begun  in  Sec¬ 
tion  3.2.  In  these  final  tests,  AAARF  is  tested  against  the  requirement  specification 
to  insure  that  all  requirements  are  met.  "Alpha  testing  and  beta  testing  are  con¬ 
ducted  to  uncover  the  errors  that  only  an  end-user  can  find.  Alpha  testing  is  done 
at  the  developers  site  with  the  developer  ‘looking  over  the  shoulder’  of  the  user,  and 
beta  testing  is  done  at  the  users  site  without  the  d(  'eloper”  [21:5 15].  In  this  inves¬ 
tigation,  alpha  testing  is  conducted  in  the  AFIT  graphics  lab  with  several  student 
and  instructor  end-users.  Beta  testing  is  discussed  in  Chapter  5.3. 

4-5  Sun  View 

Sun  View  is  ein  object-oriented  system  that  provides  a  set  of  visual  building 
blocks  for  assembling  user  interfaces.  SunView  objects  include  windows,  pointers, 
icons,  menus,  alerts,  panel  items,  eind  scrollbars.  It  also  provides  a  notification-based 
input  system.  AAARF  makes  extensive  use  of  SunView  objects  and  the  SunView 
Notifier. 
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Sun  View  Objects.  The  highest  level  object  class  in  SunView  is  the  Object  (a 
rather  confusing  name  for  an  object  claiss).  Window  is  a  subcleiss  of  Object,  and 
Subwindow  a  subclass  of  Window.  Figure  4.1  depicts  the  SunView  object  class 
hierarchy  and  instances  of  each  class.  The  following  SunView  object  descriptions  are 
taken  from  the  SunView  Programmer’s  Guide  [28]. 


Figure  4.1.  SunView  Objects  [28:10] 
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Window  Objects.  Window  objects  include  Frames  and  Subwindows.  Frames 
contain  non-overlapping  Subwindows  within  their  borders.  There  are  four  types  of 
Subwindows  provided  by  SunView; 

•  Panel  Subwindow  —  A  Subwindow  conteiining  Panel  Items. 

•  Text  Subwindow  —  A  Subwindow  containing  text. 

•  Canvas  Subwindow  —  A  Subwindow  into  which  programs  can  draw. 

•  TTY  Subwindow  —  A  terminal  emulator,  in  which  commands  can  be  given 
and  programs  executed. 

Other  Visual  Objects.  The  other  types  of  objects,  like  Windows,  are  dis¬ 
played  on  the  screen,  but  they  differ  from  Windows  in  that  they  aure  less  general  and 
more  tailored  to  their  specific  function.  They  include: 

•  Panel  Item  —  A  component  of  a  Panel  that  facilitates  a  pairticular  type  of 
interaction  between  the  user  and  the  application.  There  are  several  types  of 
Panel  Items,  including  buttons,  message  items,  choice  items,  text  items,  and 
sliders.  Figure  4.2  shows  some  examples  of  SunView  panel  items, 

•  Scrollbar  —  An  object  attached  to  and  displayed  within  a  Subwindow  through 
which  a  user  can  control  which  portion  of  the  Subwindow's  contents  are  dis¬ 
played. 

•  Menu  —  An  object  through  which  a  user  makes  choices  and  issues  commands. 
Menus  pop  up  when  the  user  presses  the  right  mouse  button. 

•  Alert  —  A  rectangular  region  on  the  screen  which  informs  the  user  of  some 
conditions.  It  has  one  or  more  buttons  which  the  user  can  push  to  dismiss 
the  Alert  or  choose  a  means  of  continuing.  Figure  4.3  shows  an  example  of  a 
SunView  alert. 

•  Pointer  —  The  object  indicating  the  mouse  location  on  the  screen. 

•  Icon  —  A  small  image  that  represents  the  SunView  application  on  the  SunView 
work  screen.  [28:11-12] 
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Panel  aessaga  Itaa  (na  Input  hare). 
Panel  text  Itea:  Input  text  her^ 


Panel  Button 


Panel  Selector  (nay  look  like  a  betton:  use  rleht  Button  to  pop  up  aenu 


Panel  Cycle  Iten  :  Ocholcel 

Panel  slider:  [58]  8 

1  188 

Check  box  toggle  Itea  ^ 

Figure  4.2.  SunView  Panel  Item  Examples 


Figure  4.3.  SunView  Alert  Example 
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The  SunView  Notifier.  SunView  is  a  notification-based  system.  The  Notifler 
acts  &s  the  controlling  entity  within  an  application,  reading  UNIX  input  from  the 
kernel,  and  formatting  it  into  higher-level  events,  which  it  distributes  to  the  appro¬ 
priate  SunView  objects.  The  Notifier  notifies,  or  Ccills,  various  procedures  which  the 
application  has  previously  registered  with  the  Notifier  [28:20].  These  procedures  are 
called  notify  procedures.  The  SunView  Notifier  model  is  shown  in  Figure  4.4. 


Figure  4.4.  SunView  Notifier  Model  [28:23] 
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4-6  Implementation  Decisions 

One  of  the  first  major  implementation  decisions  is  how  should  the  multiple 
algorithm  classes  be  managed.  Another  issue  involves  determining  what  can  be  done 
to  help  the  client-programmer  develop  new  algorithm  animations.  These  and  related 
decisions  are  addressed  in  this  section. 

Managing  Algorithm  Classes  Figure  2.5  shows  tin  idealistic  abstract  model 
of  an  algorithm  animation  system  in  which  a  library  manager  provides  an  interface 
through  which  client-programmers  manage  algorithm  animation  components,  and  an 
environment  manager  provides  an  interface  through  which  end-users  select  algorithm 
components  to  create  interesting  algorithm  animations.  In  software,  the  concept  of  a 
component  library  is  extremely  complicated  and  difficult  to  implement.  Component 
compatibility  and  dependencies  have  to  be  maintained  amd  checked  every  time  the 
end-user  makes  a  selection. 

A  more  practical  implementation  approach  is  to  develop  an  algorithm  class 
library.  Each  element  of  the  library  is  tin  independent  algorithm  class  process,  con¬ 
sisting  of  the  input  generators,  algorithms,  and  views  associated  with  the  algorithm 
class.  This  approach  eliminates  the  need  for  compatibility  and  dependency  checking 
by  taking  advantage  of  the  following  characteristics  of  eilgorithm  classes; 

•  Algorithms  in  the  same  algorithm  class  operate  on  identical  data  structures, 

•  A  view  that  can  be  used  with  one  algorithm  can  be  used  with  nearly  any 
other  algorithm  from  the  same  algorithm  class.  This  says  nothing  about  the 
effectiveness  of  the  view. 

•  An  input  generator  that  can  be  used  with  one  algorithm  can  be  used  with  any 
other  algorithm  from  the  same  edgorithm  cleiss. 

•  Most  input  generators  and  views  are  not  shared  across  algorithm  classes. 
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There  remains  the  problem  of  how  to  incorporate  the  algorithm  class  library 
into  the  eilgorithm  animation  system.  By  design,  the  algorithm  cleiss  library  is  a  dy¬ 
namic  entity;  it’s  envisioned  that  client-programmers  will  add  new  algorithm  classes 
to  AAARF  indefinitely.  Three  possible  solutions  are  proposed: 

1.  Link  the  algorithm  class  library  to  the  main  animation  system  to  produce  a 
single  AAARF  executable  program.  Two  obvious  problems  with  this  solution 
are  (1)  the  size  of  the  executable  image  is  a  function  of  the  size  of  the  library 
and  (2)  even  if  some  sort  of  dynamic  linking  [27:52-53]  is  used  to  reduce  the  size 
of  the  executable  image,  the  system  has  to  be  compiled  and  linked  every  time 
a  change  is  made  to  an  algorithm  component.  This  situation  becomes  very 
complicated  when  two  programmers  are  developing  and  testing  two  different 
algorithm  animations  simultaneously. 

2.  Develop  some  method  to  dynamically  load  algorithm  class  object  files  from 
the  algorithm  class  library  and  link  to  them  while  the  AAARF  program  is 
executing.  This  is  similar  to  the  first  solution  except  that  in  this  case,  the 
main  program  is  not  'inked  with  the  algorithm  class  until  execution  time.  This 
solution  eliminates  the  need  to  compile  and  link  every  time  an  algorithm  com¬ 
ponent  is  modified  and  permits  parallel  development  of  algorithm  animations. 
However,  it’s  difficult  to  implement  and  entails  some  overhead  for  managing 
the  execution-time  loading  eind  linking. 

3.  Let  the  algorithm  class  library  consist  of  independent  executable  algorithm 
class  programs  which  are  invoked  by  a  central  animation  environment  manager 
as  separate  processes  and  controlled  via  some  form  of  interprocess  communi¬ 
cation  (IPC)  [25:192-200].  This  solution  creates  one  executable  image  for  each 
algorithm  class  plus  a  high-level  animation  manager  program.  It  provides  for 
parallel  development  of  algorithm  animations  and  is  simple  to  implement.  This 
approach  is  selected  for  implementation. 
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The  third  approach  provides  a  flexible  animation  environment  for  the  end-user 
and  a  manageable  development  environment  for  the  client-programmer.  AAARF 
consists  of  a  central  process  that  invokes  and  controls  multiple  algorithm  class  pro¬ 
cesses.  The  central  process  is  referred  to  as  the  main  process,  the  environment 
manager,  or  AAARF  depending  on  the  context.  The  algorithm  class  processes  are 
referred  to  as  algorithm  processes  or  class-specific  processes.  The  algorithm  processes 
are  essentially  stand-alone  except  for  the  IPC  hooks  to  the  main  process. 

UNIX  sockets  [25:191-217]  provide  the  IPC  facilities  for  the  main  AAARF 
procedure  to  control  algorithm  class  processes.  The  UNIX  IPC  interface  makes  IPC 
similar  to  file  I/O.  A  process  has  a  set  of  I/O  descriptors  for  reading  and  writing. 
The  descriptor  may  refer  to  files,  devices,  or  communications  channels. 

Managing  Algorithm  ComponenU  Given  that  algorithm  classes  are  imple¬ 
mented  as  separate  processes  with  IPC  hooks  to  the  main  AAARF  process,  how 
should  an  algorithm  process  be  implemented?  The  problem  is  that  both  the  algo¬ 
rithm  component  and  the  view  component  require  access  to  the  data  structure  being 
manipulated  by  the  algorithm.  In  addition,  the  algorithm  component  needs  some 
mechanism  for  reporting  interesting  events  to  the  view  component.  There  must  also 
be  a  mechanism  for  controlling  (starting,  stopping,  breaking,  etc)  the  animation. 

The  algorithm  animation  component  model  (Figure  2.3)  suggests  a  solution. 
The  component  model  forms  a  pipeline  which  drives  the  graphic  representation  dis¬ 
played  on  the  view  windows.  The  input  component  drives  the  algorithm  component; 
the  algorithm  component  drives  the  view  component;  and  the  view  component  gen¬ 
erates  the  graphics  commands.  Figure  4.5  shows  a  slightly  modified  version  of  the 
algorithm  animation  component  model.  In  this  version,  the  view  component  requests 
and  receives  interesting  events  from  an  abstract  interesting  event  generator.  The  in¬ 
teresting  event  generator  may  be  an  algorithm  component,  a  software  recording  of 
interesting  events,  or  an  unknown  source  on  a  remote  computer  system. 
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Figure  4.5.  Extended  Algorithm  Animation  Component  Model 

AAARF  algorithm  processes  are  composed  of  two  levels:  an  interesting  event 
generator  and  a  view  generator.  These  two  levels  are  implemented  as  separate  pro¬ 
cesses.  Both  processes  require  access  to  the  same  data  structure.  This  can  be  handled 
in  a  couple  of  different  ways: 

•  Shared  memory  —  both  processes  access  the  data  structure.  This  method 
requires  some  contention  and  data  locking  consideration  to  protect  the  data 
from  accidental  corruption  through  simultaneous  access  by  both  processes. 

•  iPC  —  each  process  keeps  a  copy  of  the  data  structure.  The  interesting  event 
generator  determines  what  action  is  taken  on  the  data  structure  and  informs 
the  view  generator  via  socket-based  IPC.  This  method  is  easier  to  implement 
and  makes  it  easy  to  animate  algorithms  that  aje  running  on  remote  hosts. 

The  view  generator  process  consists  of  the  view  component  and  is  referred  to 
as  the  claiss- specific  window-based  process.  The  interesting  event  generator  process 
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consists  of  the  input  and  algorithm  components  and  is  referred  to  as  the  class-specific 
background  process.  The  background  process  generates  interesting  events  for  the 
window-bcLsed  process.  Socket-based  IPC  is  used  to  request  and  report  interesting 
events  and  to  exchange  parameters.  By  associating  a  polling  timer  wii.-  the  view 
component,  the  SunView  Notifier  calls  the  view  component  at  appropriate  intervals 
to  update  the  animation.  The  animation  is  controlled  through  the  view  component. 

AAARF  Architecture  Summary.  This  section  summarizes  the  results  of  the 
preceding  sections.  AAARF  uses  three  levels  of  execution  linked  via  UNIX  sockets 
to  implement  the  algorithm  animation  system  model.  Figure  4.6  shows  the  levels  of 
execution. 

The  AAARF  Main  Process.  AAARF’s  top-level  process  acts  as  the  envi¬ 
ronment  manager.  It  provides  the  main  screen,  a  mechanism  for  saving  and  restoru:g 
animation  environments,  a  mechanism  for  controlling  multiple  algorithm  animations 
simultaneously,  and  a  means  for  starting  new  algorithm  animations. 

The  Class-Specific  Window-Based  Process.  The  middle  level  of  execu¬ 
tion  is  the  class-specific  window-b€ised  process.  The  window-based  level  of  execution 
provides  the  animation  views,  an  animation  recorder,  a  status  display  for  interro¬ 
gating  the  state  of  the  algorithm,  and  a  master  control  panel  for  monitoring  and 
modifying  the  parameters  that  affect  the  animation.  The  view  component  of  Fig¬ 
ure  2.5  is  implemented  at  this  le/el. 
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Figure  4.6.  AAARF  Levels  of  Execution 

The  Class-Specific  Background  Process.  The  lowest  level  of  execution 
is  transparent  to  the  user;  this  level  implements  the  input  generator  and  algorithm 
components  of  the  algorithm  animation  system  model  (Figure  2.5).  It  provides  the 
window-based  level  with  the  lEs  that  drive  the  animation.  The  background  process 
waits  with  an  IE  until  the  window-based  level  sends  an  IE  request.  The  background 
process  sends  the  IE,  then  resumes  execution  of  the  algorithm.  At  the  next  IE,  the 
background  process  again  stops  and  waits  for  an  IE  request  from  the  window-based 
p:of  .ess.  Figure  4.7  shows  the  background  process  model. 
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Figure  4.7.  Background  Process  Structure 
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AAARF  Class-Common  Library.  Each  algorithm  cIeiss  that  AAARF  invokes 
is  actually  a  stand  alone  process.  Without  the  communication  links  to  AAARF,  the 
process  could  be  executed  without  the  AAARF  main  process.  Every  algorithm  class 
process  is  characterized  by  the  following  initialization  sequence: 

•  Get  setup  parameters  from  AAARF, 

•  Create  base  window  for  animation, 

•  Create  the  master  control  panel, 

•  Create  the  algorithm  window  menu, 

•  Create  the  animation  canvases  (views), 

•  Create  the  animation  recorder, 

•  Create  the  status  display, 

•  Run  the  background  process, 

•  Paint  the  active  canvases, 

•  Enter  the  SunView  main  loop. 

The  AAARF  class-common  library  presents  client-programmers  a  framework 
for  developing  new  algorithm  animations  by  providing  all  the  common  functions. 
The  client-programmer  simply  develops  the  class-specific  input,  algorithm,  view, 
and  control  functions.  Because  the  class-common  library  depends  on  some  class- 
specific  data  structures,  linkable  object  code  is  not  provided,  only  source  code.  The 
class-common  framework  must  be  recompiled  for  each  new  algorithm  class.  This 
limitation  could  be  eliminated  in  a  future  version  of  AAARF. 

Not  only  does  the  AAARF  class-common  library  make  animation  development 
easier  for  client-programmers,  it  also  forces  a  consistent  animation  interface  for  the 
end-user.  Every  algorithm  class  supports  the  same  set  of  tools,  and  those  tools  work 
identically  for  every  algorithm  class.  After  animating  one  algorithm,  end-users  can 


animate  any  algorithm,  regardless  of  the  algorithm  cleiss  or  its  client-programmer. 
The  class-common  library  also  ensures  a  consistent  communicatiouo  interface  with 
the  AAARF  main  process. 

Appendix  D  describes  the  process  of  creating  new  adgorithm  animation  in  some 
detail.  It  explains  what  is  provided  by  the  class-common  library  and  what  is  required 
from  the  client-programmer. 

Program  Documentation.  The  existing  source  code  is  fully  documented  in  ac¬ 
cordance  with  AFIT  System  Development  Documentation  Guidelines  and  Standards 
[14].  Most  functions  are  less  than  one  page  long  and  most  modules  contain  less  than 
ten  functions. 

4 . 7  Summary 

This  chapter  described  the  AAARF  detailed  design  and  implementation.  Im¬ 
plementation  essentially  consisted  of  the  top-down  mapping  of  AAARF  design  ob¬ 
jects  to  their  corresponding  SunView  objects.  The  AAARF  Programmer’s  Guide 
(Appendix  D)  and  the  AAARF  User’s  Manual  (Appendix  C)  discuss  the  implemen¬ 
tation  and  operation  of  AAARF  in  greater  detail.  Both  documents  include  many 
illustrations  of  actual  AAARF  screen  images. 

The  test  methodology,  design  technique,  and  implementation  approach  were 
also  discussed.  Important  implementation  decisions  were  presented  in  detail.  The 
implementation  relies  heavily  on  the  SunView  window-based  environment;  the  Sun- 
view  objects  and  Notifier  were  discussed.  In  the  next  chapter  AAARF  is  evaluated, 
and  recommendac’ons  for  further  research  are  offered. 
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V.  Conclusions  and  Recommendations 


5. 1  Introduction 

This  chapter  presents  the  results  of  the  AAARF  system  testing  and  an  eval¬ 
uation  of  AAARF’s  functionality  and  educational  value.  Based  on  the  test  results 
and  evaluation,  conclusions  and  directions  for  future  research  are  presented. 

5.2  System  Testing 

AAARF  passed  all  aspects  of  white  box  testing  (Section  3.2);  every  function 
operates  as  designed.  There  are  no  known  programming  errors.  As  for  black  box 
testing,  not  every  requirement  from  the  enumerated  requirements  specification  was 
implemented.  The  remainder  of  this  section  discusses  each  of  the  unimplemented 
requirements. 

Pan  and  Zoom.  The  pan  and  zoom  features  for  view  windows  (Requirement 
1.14)  were  not  implemented.  With  the  Sun  View  Scrollbar  object,  these  capabilities 
should  be  easy  to  add.  However,  not  all  animations  benefit  from  the  pan  and  zoom 
capabilities;  either  the  end-user  or  the  client- programmer  must  decide  if  a  particular 
view  should  support  the  capabilities.  The  simplest  solution  is  to  require  that  zdl 
animations  support  panning  and  zooming,  then  the  decision  to  display  the  pan  and 
zoom  controls  (presumably  Scrollbars)  is  left  to  the  user. 

Reverse  Playback  of  Animations.  The  animation  recorder  reverse  play¬ 
back  feature  (Requirement  1.55)  Wcis  not  implemented.  The  recorder  panel  shows  a 
reverse  playback  button,  but  hitting  the  button  reveals  a  message  explaining  that 
the  feature  is  not  currently  available. 
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Running  an  algorithm  in  reverse  is  no  simple  matter.  As  an  animation  pro¬ 
gresses,  every  interesting  event  affects  a  unique  change  to  the  algorithm  state  struc¬ 
ture. 

IE 

qk  —*■  qk+i 

The  animation  recorder  works  by  adding  each  new  interesting  event  to  the  end  of 
a  doubly-linked  list.  The  list  is  doubly-linked  ostensibly  for  traversal  in  both  di¬ 
rections  during  playback.  The  recorder  flawlessly  delivers  interesting  events  in  the 
forward  direction,  exactly  duplicating  a  previously  recorded  animation.  The  anima¬ 
tion  recorder  can  also  reliably  deliver  interesting  events  in  reverse  order,  however 
interesting  events  alone  cannot  transform  the  current  algorithm  state  to  a  unique 
previous  state: 

IE 

qk  -h  qk-1 

Animations  cannot  be  played  in  reverse  ba^ed  solely  on  interesting  events;  more 
information  has  to  be  available  regarding  the  algorithm  state  before  an  interesting 
event  occurred.  The  problem  is  definitely  solvable,  but  implementing  the  solution 
required  more  time  than  was  available,  so  this  feature  was  left  unimplemented. 

Automatic  Validation  of  Animation  Library.  The  requirement  for  au¬ 
tomatic  validation  of  changes  to  the  animation  library  (Requirement  2.2)  was  not 
explicitly  addressed.  Since  the  animation  library  is  actually  a  distributed  collection 
of  executable  processes,  any  subset  of  which  may  be  accessed  by  AAARF  during 
a  particular  session,  it  is  difficult  to  define,  much  less  validate,  changes  to  the  li¬ 
brary.  The  idea  of  an  animation  library  is  actually  an  abstraction  of  the  collection  of 
executable  processes;  the  automatic  validation  is  provided  by  the  development  envi¬ 
ronment  tools  —  the  compiler,  the  linker,  lint,  etc.  Whether  or  not  this  requirement 
has  been  met  is  arguable;  in  any  Ccise,  no  specific  tools  were  created  to  support  this 
requirement. 
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Library  of  Animation  Primitives.  The  library  of  animation  primitives 
(Requirement  2.3)  Weis  not  implemented.  A  library  of  animation  primitives  is  an 
important  step  toward  simplifying  the  creation  of  zdgorithm  animations,  but  the 
development  of  such  a  library  is  an  undertaking  that  is  beyond  the  scope  of  this 
study.  The  SunView  Pixrect  library  provides  several  powerful  graphics  primitives, 
but  provides  nothing  to  directly  support  animation. 

5.S  Evaluation  of  A  A  ARE 

Satisfying  the  functional  requirements  and  producing  error-free  code  are  cer¬ 
tainly  desirable  goals  for  any  software  engineering  project,  but  in  the  case  of  AAARF, 
some  important  questions  remain; 

•  Can  end-users  effectively  use  it? 

•  Is  it  of  2my  use  to  end-users? 

•  Can  client-programmers  create  new  algorithm  animations? 

•  Will  it  run  on  other  hosts? 

The  first  three  questions  cannot  be  completely  emswered  until  a  substantial  number 
of  end-users  and  client-programmers  are  surveyed.  Such  a  survey  is  currently  under¬ 
way  as  part  of  the  AAARF  beta  testing.  In  conjunction  with  the  AFIT’s  Advanced 
Algorithms  and  Data  Structures  course,  students  are  using  AAARF  to  study  spe¬ 
cific  algorithm  behavior  and  to  develop  new  algorithm  einimations.  Based  on  their 
experiences  with  AAARF,  the  students  complete  a  questionnaire  [15]  (Appendix  B) 
designed  to  evaluate  AAARF’s  educational  value  as  well  as  its  user- interface  and 
functionality. 

No  formal  user  evaluations  have  been  collected  yet.  However,  several  end-users 
and  one  client-programmer  used  AAARF  during  its  alpl  a  testing.  The  remainder 
of  this  section  addresses  each  question  based  on  observations  made  during  the  alpha 
test  period. 
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Functionality.  With  few  exceptions,  AAARF  follows  the  user  interface  con¬ 
ventions  recommended  by  Sun  [28:469-474]  and  used  by  nearly  all  Sun  View  ap¬ 
plications.  Veteran  Sun  workstation  users  can  view  algorithm  animations  almost 
immediately.  Even  end-users  who  are  unfamiliar  with  SunView  can  view  simple  al¬ 
gorithm  animations  within  three  to  five  minutes  of  beginning  their  first  session  with 
AAARF. 

AAARF  offers  many  options  for  selecting,  controlling,  amd  viewing  algorithms. 
Despite  numerous  pop-up  help  screens,  naive  users  are  occaisionally  unaware  of  some 
system  features.  The  help  screens  describe  every  feature  that  can  be  accessed  from 
the  window,  panel,  or  menu  associated  with  the  help  message.  The  user  surveys 
should  reveal  whether  the  “naive  user  problem”  is  a  fault  of  the  system  or  a  charac¬ 
teristic  of  the  user. 

Because  so  many  options  are  available,  the  AAARF  main  window  can  become 
littered  with  algorithm  windows  and  their  panels  —  it’s  possible  to  have  14  control 
panels  and  16  view  windows  open  simultaneously.  Visually  managing  that  much 
information  is  difficult  to  say  the  leeist.  There  is  very  little  automatic  window  layout. 
On  color  systems,  algorithm  windows  and  their  associated  panels  are  color-coded.  On 
monochrome  systems,  it  is  nearly  impossible  to  tell  with  which  algorithm  window  a 
particular  control  panel  is  associated.  The  problem  is  a  consequence  of  the  flexibility 
given  to  the  user.  Limiting  the  flexibility  could  reduce  the  potential  complexity 
of  the  displays,  but  would  stifle  the  users  ability  to  create  unique  and  interesting 
animation  environments.  Familiarity  with  the  system  should  relieve  the  problem  for 
most  users.  The  environment  control  facility  can  also  help  with  the  problem;  complex 
arrangements  of  windows,  panels,  and  p<irameters  can  be  saved  and  restored  quickly 
and  with  no  confusion. 


I 
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Educational  Value.  David  Scanlan  conducted  research  on  leaxner  preferences 
for  graphic  or  verbal  algorithmic  presentation  techniques  and  found  that  “graphical 
expressions  of  algorithms  seem  more  helpful  to  most  students  than  verbal  expres¬ 
sions”  [22:176].  Considering  that  78%  of  the  students  he  surveyed  preferred  graphi¬ 
cal  presentations,  his  findings  seem  believable.  But,  there  is  some  skepticism  toward 
program  visualization  —  Edsger  Dijkstra  states 


I  was  recently  exposed  to  a  demonstration  of  what  wjis  pretended  to  be 
educational  software  for  an  introductory  programming  course.  With  its 
“visualizations”  on  the  screen  it  was  such  an  obvious  case  of  curriculum 
infantilization  that  its  author  should  be  cited  for  “contempt  of  the  student 
body,”  . . .  We  must  expect  from  that  system  permanent  mental  damage 
for  most  students  exposed  to  it.  [ll:xxxvii] 

Expert  opinion  notwithstanding,  experience  with  AAARF  has  shown  that  that 
end-users  can  learn  how  an  algorithm  works  from  a  “good”  view  of  the  algorithm 
in  execution.  What  makes  a  “good”  view  varies  from  one  algorithm  to  the  next. 
Within  the  sorts  class,  the  tree  view  works  well  with  heap  sort,  the  sticks  view  with 
shaker  sort,  and  the  dots  view  with  quick  sort.  Allowing  the  user  to  select  any  of 
several  possible  views,  permits  them  to  find  their  own  particular  “good”  view. 

Unfortunately,  only  two  cdgorithm  classes  have  been  implemented  for  AAARF 
so  far  —  sorts  and  binary  tree  traversals.  Based  on  these  two  classes  it’s  difficult  to 
determine  the  geuered  educational  vcilue  of  AAARF.  As  for  the  extent  of  the  mental 
damage  to  end-users,  only  time  will  tell! 

Creating  Algorithm  Animations.  The  sorts  class  was  developed  along 
with  the  AAARF  main  process  and  the  class-common  library.  The  binary  tree 
traversals  class  was  developed  by  an  independent  client-programmer.  While  one 
client-programmer  success  does  not  provide  sufficient  grounds  for  claiming  an  effec¬ 
tive  client-programmer  interface,  it  does  show  that  client-programmers  can  use  the 
class-common  library  to  build  algorithm  animations.  More  client-programmers  must 
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use  AAARF  before  any  conclusions  can  be  drawn  regarding  the  effectiveness  of  the 
client-progrcunmer  interface. 

The  binary  tree  traversals  cl2iss  made  use  of  the  tree  view  from  the  sorts  class. 
Some  modifications  were  required  to  reflect  the  unique  nature  of  the  traversal  algo¬ 
rithm  state  representation,  but  the  views  are  essentially  identical.  Thus,  eilgorithm 
components  can  be  reused.  As  more  animations  are  created,  it  will  be  easier  for 
client-programmers  to  draw  from  existing  views  and  input  generators. 

Portability.  AAARF  was  designed  to  execute  on  Sun3  amd  Sun4  workstations. 
It  Weis  developed  primarily  on  a  Sun4  workstation.  Due  to  the  strong  dependency 
on  SunView,  it  is  unlikely  that  the  top  two  levels  of  AAARF  can  execute  on  any 
other  computer,  however  the  low-level  background  process  can  execute  on  any  ma¬ 
chine  that  is  reachable  with  socket-based  IPC.  AAARF’s  view  procedures  are  not 
particuleir  about  the  source  of  their  interesting  events  —  a  local  background  process, 
the  animation  recorder,  or  a  remote  system.  As  long  as  socket-based  IPC  is  possible, 
the  input  generator  and  algorithms  can  be  controlled  and  interesting  events  can  be 
retrieved. 

There  are  some  portability  problems  with  AAARF.  It  requires  more  resources 
than  some  systems  are  configured  to  provide.  In  most  ceises,  the  program  will  run, 
but  with  limited  capabilities;  less  than  four  algorithm  windows  can  be  opened  si¬ 
multaneously.  It’s  difficult  to  determine  exact  system  requirements  because  other 
processes  running  on  the  system  affect  resource  avaulability.  AAARF’s  notable  re¬ 
source  requirements  are  in  two  areas;  memory  and  window  devices.  Both  of  these 
resources  are  controlled  by  the  system  administrator. 

•  With  up  to  sixteen  animation  canvases  opened  simultaneously,  AAARF  uses 
a  lot  of  memory.  The  amount  of  memory  is  directly  proportional  to  the  size 
and  number  of  open  canvases.  Rather  than  reduce  the  maximum  number  of 
views  or  algorithm  windows,  the  size  of  the  animation  canvas  is  reduced.  The 


AAARF  administrator  sets  the  window  size  to  the  largest  size  that  does  not 
cause  the  system  to  run  out  of  memory.  A  800  x  800  pixel  canvas  works  for 
most  systems. 

•  AAARF  uses  64  window  devices.  Since  the  user  normally  has  several  other 
sunview  windows  open  at  least  96,  possibly  128,  window  devices  must  be 
installed  in  the  /dev  directory.  On  systems  which  only  have  64  window  devices 
installed,  only  two  algorithm  windows  can  be  opened. 

5-4  ConcliLsions 

Bzised  on  the  work  performed  during  this  study,  this  section  presents  the  con¬ 
clusions  reached  regarding  AAARF  and  algorithm  animation. 

Literature  Review.  The  literature  review  was  an  essential  part  of  this  de¬ 
velopment.  Several  previous  algorithm  animation  systems  were  reviewed  and  as¬ 
pects  of  each  influenced  AAARF:  Baecker’s  displays  from  “Sorting  out  Sorting”, 
balsa’s  displays  and  Brown’s  input-algorithm-view  paradigm  for  algorithm  anima¬ 
tion,  Kernighan’s  and  Bentley’s  animation  pipeline,  London’s  and  Duisberg’s  object- 
oriented  approach,  and  TANGO’s  animation  library.  It  is  unlikely  that  AAARF 
could  have  succeeded  without  the  guidance  of  these  previous  research  efforts. 

Object-Oriented  Design.  The  object-oriented  design  technique  worked  well 
for  designing  an  algorithm  animation  system.  The  animation  system  was  easily 
partitionable  into  objects. 

SunView.  The  SunView  window-based  environment  provided  an  excellent 
basis  from  which  to  implement  an  algorithm  animation  system.  SunView  directly 
supported  all  of  the  high-level  graphical  objects  defined  in  AAARF’s  preliminary 
design. 

Sun  Workstations.  A  Sun4  workstation  configured  with  50  megabytes  of 
swap  space  and  128  window  devices  was  an  outstanding  host  machine  for  an  al- 
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gorithm  animation  system.  Other  system  configurations  worked,  but  usually  with 
limited  capabilities. 

Color  Monitors.  Color  monitors  provide  much  more  informative  displays 
than  monochrome  monitors.  Texture  patterns  help  monochrome  monitors  to  emulate 
color,  but  there  is  no  substitute  for  bright  colors  when  attempting  to  bring  a  viewers 
attention  to  a  particular  aspect  of  a  graphical  image. 

End-User  Functionality.  End-users  can  animate  algorithms  with  AAARF. 
Figure  5.1  shows  an  AAARF  display  of  four  sort  algorithms.  While  only  two  algo¬ 
rithm  classes  have  been  implemented,  there  is  no  reason  to  suspect  that  an  algorithm 
class  exists  that  cannot  be  animated. 


Figure  5.1.  Animation  of  Four  Sorting  Algorithms 
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Client-Programmer  Functionality.  Client-programmers  can  create  new 
AAARF  algorithm  animations.  Only  two  classes  have  been  implemented,  but  the 
utility  of  the  class-common  library  hcis  been  clearly  demonstrated  through  those 
implementations. 

Teaching  Algorithms  Through  AAARF.  Algorithms  can  be  learned  from 
animations  of  their  execution  on  AAARF.  Whether  cinimation  is  a  better  method 
for  learning  algorithms  than  conventional  methods  is  a  matter  for  further  study. 

The  Difficulty  of  Animating  Algorithms.  Creating  dgorithm  animations 
is  not  easy.  There  are  several  difficulties: 

•  Identifying  an  algorithm’s  interesting  events, 

•  Selecting  an  abstract  representation  for  the  adgorithm  state, 

•  Implementing  the  abstract  representation, 

t  Presenting  the  implementation  (size,  position)  on  the  screen, 

•  Animating  vhe  representation  (transitions  between  images), 

•  Updating  the  animation  displays  (timing,  speed), 

•  Bringing  attention  to  cireas  of  interest. 

It  is  due  to  these  difficulties  that  automatic  animation  of  algorithms  seems  unlikely. 
Figure  5.2  shows  four  views  of  a  heap  sort  algorithm;  none  of  the  views  were  generated 
solely  on  the  basis  of  changes  to  the  data  structure  —  all  of  the  views  require  some 
information  regarding  the  nature  of  the  changes  to  the  data  structure. 
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Figure  5.2.  Four  Views  of  a  Heap  Sort 

5.5  Recommendations  for  Further  Research 

Based  on  the  results  of  this  study  and  the  observations  made  during  it,  this 
section  presents  some  recommendations  for  further  research  and  some  suggestions 
for  enhancing  AAAP.F. 

The  Value  of  Algorithm  Animation.  Before  too  much  time  is  spent  de¬ 
veloping  more  algorithm  animations,  a  study  should  be  conducted  to  determine  if 
there  is  sufficient  cause  to  do  so.  Can  end-users  learn  more  or  faister  with  algorithm 
animation  than  with  conventional  teaching  methods?  Is  algorithm  animation  useful 
for  debugging? 

Remotely-Hosted  Algorithm  Components.  The  animation  of  algorithms 
executing  on  remote  hosts  is  an  'nteresting  area  of  research.  These  animations  could 
reveal  not  only  aspects  of  the  algorithm,  but  features  of  the  host  architecture  as 
well.  For  example,  a  variety  of  interconnection  networks  could  be  compared  for 
sorting  arrays  of  numbers,  performing  matrix  operations,  or  numerical  integration 
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on  a  parallel  computer  system. 

Unimplemented  Features.  The  remaining  requirements  of  the  enumerated 
requirements  specification  should  be  implemented  (see  Section  5  2).  In  particular, 
the  library  of  animation  primitives  greatly  increase  the  client-programmers  ability 
to  develop  new  animations. 

Enhancements.  Several  enhancements  could  be  made  to  increase  the  useful¬ 
ness  and  improve  the  performance  of  AAARF: 

Extended  Recorder  Capability.  Every  algorithm  should  be  recorded  as  it  is 
being  animated.  This  would  allow  the  user  to  hit  reverse  at  any  time  to  review 
a  particularly  interesting  portion  of  an  animation.  While  the  software  “tape”  is 
playing,  the  background  process  waits  with  the  next  “live”  interesting  event.  The 
transition  from  “tape”  to  “live”  should  be  not  be  apparent  to  the  end-user.  The 
recorder  panel  could  be  elirndnaced  and  incorporated  into  the  master  control  panel. 

Recording  Control  Information.  The  animation  recordings  should  also  include 
control  information  —  speed  changes,  starts,  stops,  and  break-points.  This  is  similar 
to  the  “scripts”  used  by  Marc  Brown  in  BALSA  [6:71].  It  allows  a  user  to  create  a 
“movie”  which  emphasizes  particular  sequences  that  the  user  feels  are  particularly 
interesting  or  important. 

Timing  of  Animation  Updates.  Currently  AAARF  is  at  the  mercy  of  the 
SunOS  scheduler  with  respect  to  the  sequential  updating  of  the  displays  for  mul¬ 
tiple  algorithms.  This  can  produce  misleading  results.  There  should  be  some  way  of 
(1)  controlling  which  algorithm  is  next  to  update  its  display,  and  (2)  applying  a  dis¬ 
play  time  weighting  factor  to  algorithm  events  that  is  proportional  to  the  time  th^tt 
ihe  event  would  actually  take  in  execution.  For  example,  in  the  sort  algorithm  class, 
the  IN_PLACE  interesting  event  is  a  conceptual  event  that  actually  takes  no  time 
to  execute,  but  it  is  given  the  same  amount  of  display  time  as  as  the  EXCHANGE 
interesting  event  which  obviously  takes  signiFcantly  more  time  in  execution. 
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Automatic  Views  of  Code.  Perhaps  the  best  ways  of  presenting  an  algorithm 
is  a  combination  of  text  and  graphics.  An  automatic  display  of  the  algorithm  text 
along  with  the  animation  might  improve  a  users  understanding  of  the  algorithm  and 
be  useful  for  debugging.  The  currently  executing  instruction  could  be  highlighted 
within  the  text  display. 

Portability  Problems.  With  respect  to  portability,  AAARF  actually  has  two 
problems.  The  first  has  to  do  with  the  resource  requirements  of  AAARF.  It’s  possible 
that  AAARF  could  be  optimized  so  that  fewer  resources  are  required  for  its  execu¬ 
tion.  Also,  a  better  estimate  of  the  minimum  system  configuration  should  be  devel¬ 
oped.  The  second  problem  involves  running  AAARF  on  systems  with  monochrome 
monitors.  AAARF  should  be  modified  to  directly  support  monochrome  systems  by 
using  a  variety  of  pixel  patterns  to  emulate  color. 

5.6  Summary 

The  system  testing  revealed  that  some  requirements  were  not  satisfied,  but 
that,  overall,  the  system  performed  according  to  design.  An  evaluation  of  AAARF 
showed  that  the  goals  of  “developing  a  methodology  for  creating  algorithm  ani¬ 
mations  and  developing  an  environment  for  controlling,  displaying,  and  interacting 
with  the  animations”  were  satisfied.  Conclusions  of  the  study  were  presented  and 
directions  for  future  research  were  recommended. 
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Appendix  A.  Detailed  Design 


This  appendix  contains  the  detailed  design  structure  charts  for  the  AAARF 
implementation.  The  detailed  design  is  concerned  with  developing  an  algorithmic 
abstraction  for  coordinating  the  activities  of  the  preliminary  design  objects  devel¬ 
oped  in  Chapter  III.  The  objects  and  operations  are  used  to  develop  a  high-level 
procedural  description  of  the  software.  The  following  structure  chart  conventions 
are  used; 

•  The  symbol,  sv,  in  the  lower  right  corner  of  a  design  module  indicates  that 
the  function  is  provided  by  Sun  View. 

•  The  symbol,  cp,  in  the  lower  right  corner  of  a  design  module  indicates  that 
the  function  is  required  from  the  client-programmer. 

There  is  a  close,  but  not  necessarily  a  one-to-one,  correspondence  between  the  design 
modules  and  the  program  modules.  The  AAARF  Programmer’s  Manual  provides 
more  information  regarding  the  actual  program  structure. 
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Figure  1:  Design  Module  1.0  AAARF  Main  Process 
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Figure  3;  Design  Module  1.2  Process  AAARF  Events 
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Figure  5:  Design  Module  1.2. 2. 2. 2.1  Open  Algorithm  Window 
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Figure  f.  Jesign  Module  1.2. 2. 2. 2. 3  Open  Environment  Control 
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Figure  8:  Design  Module  1.2. 2. 2. 2. 3. 2. 2.1  Load  Environment 


Figure  9:  Design  Module  1.2. 2. 2. 2. 3. 2. 2. 2  Save  Environment 
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Figure  10:  Design  Module  1.2. 2. 2. 2. 3. 2. 2. 3  Delete  Environment 
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Figure  11:  Design  Module  1.2. 2. 2. 2. 5  Quit  AAARF 
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Figure  12;  Design  Module  2.v,  iain  Algorithm  Process 
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Figure  13:  Design  Module  2.1  Create  Algorithm  Window 
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Figure  14:  Design  Module  2.1.1  Create  AlgWindow 


Figure  15:  Design  Module  2. 1.1. 4  Monitor  View  Window  Events 
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Figure  19:  Design  Module  2.3  Monitor  AAARF  Channel 


Figure  20:  Design  Module  2. 3. 2. 3  Send  Parameter  to  AAARF 
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Figure  22;  Design  Module  2.4.2. 1  Show  AlgWindow  Menu 
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Figure  23:  Design  Module  2.4.2. 1.2.2  Show  Recorder 
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Figure  24;  Design  Module  2. 4. 2. 1.2. 2. 2. 2  Load  Recording 
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ure  26;  Design  Module  2. 4. 2. 1.2. 2. 2. 4  Delete  Recording 
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Figure  28:  Design  Module  2. 4. 2. 1.2. 4  Show  Status 
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Figure  30:  Design  Module  2.5.2  Get  Interesting  Event 
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Figure  32;  Design  Module  2.5.5  Record  Interesting  Event 
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Exper: 

First: 
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PLEASE  READ  DEPORE  PROCEEDING: 

The  following  questionnaire  is  designed  to  provide  user  feedback  on  the  human-computer 
interface  of  tlie  specified  computer-aided  design  (CAD)  tool.  Through  your  responses,  we 
hope  to  measure  your  degree  of  satisfaction  with  the  tool,  with  primary  emphasis  on  the 
“user-friendliness'’  of  the  human-computer  interface. 

The  questionnaire  consists  of  a  set  of  11  factors,  plus  an  overall  rating.  V\'e  will  determine 
your  satisfaction  with  the  tool  based  on  your  response  to  six  adjective  pairs  used  to  describe 
each  factor.  Each  adjective  pair  has  a  seven-interval  range  where  you  are  to  indicate  your 
feelings  with  an  “X”.  Responses  placed  in  the  center  of  the  range  will  indicate  that  you  have 
no  strong  feelings  one  way  or  the  other,  or  that  you  cannot  effectively  evaluate  that  given 
factor. 
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1.  System  Feedback  or  Content  of  the  Information  Displayed.  The  extent  to  which  the  system  kepil  >cu 
informed  about  wliat  was  going  on  in  the  program. 


insulTicienl 

unclear 

useless 

bad 

unsatisfactory 


sufficient 

clear 

useful 

good 

satisfactory 


To  me  this  factor  is; 


unimportant 


important 


Conurients; 


2.  Communication.  The  methods  used  to  communicate  with  the  tool. 


complex 

weak 

bad 

useless 

unsatisfactory 


simple 

powerful 

good 

useful 

satisfactory 


To  me  this  factor  is: 


unimportant 


important 


Comments; 


3.  Error  Prevention  Your  perception  of  how  well  the  system  prevented  user  induced  errors. 


bad 

insufficient 

incomplete 

low 

unsatisfactory 


good 

sufficient 

complete 

high 

satisfactory 


To  me  this  factor  is: 


unimportant 


important 


Comments; 
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4.  Error  Recovery.  The  extent  and  ease  with  which  the  system  allowed  you  to  recover  from  user  induced 
errors. 


unforgiving 

incomplete 

complex 

slow 

unsatisfactory _ _ 

To  me  this  factor  is: 


forgiving 

complete 

simple 

fast 

satisfactory 


unimportant 


]  important 


CoimiKiil.s: 


5.  Docuinentation.  Your  overall  perception  as  to  the  usefulness  of  documentation. 
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hazy 

insiifTicient 
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To  me  this  factor  is: 


useful 

complete 

clear 
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satisfactory 
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I  I  I  I  I  important 
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6.  Expectations.  Your  perception  as  to  the  services  provided  by  the  system  based  on  your  expectations. 


displeased 

low 

uncertain  _  _ 

pessimistic 

unsatisfactory  _ _ 

To  me  this  factor  is: 


pleased 

high 

definite 

optimistic 

satisfactory 


unimportant 


I  I  I  I  important 


Comments: 


3 


7.  Confidence  in  the  System.  Your  feelings  of  assurance  or  certainty  about  the  services  provided  b\  the 
system. 


high 
strong 
definite 
good 

satisfactory 

To  me  this  factor  is; 


low  T 
weak 
uncertain 
bad 

unsatisfactory 


unimportant 


important 


Comments: 


8.  Ease  of  Learning.  Ease  with  which  you  were  able  to  learn  how  to  use  the  system  to  perform  the 
intended  task. 


difficult 

confusing 

complex _ 

slow 
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easy 

clear 

simple 

fast 
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unimportant 
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Comments: 


9.  Display  of  Information.  The  manner  in  which  both  program  control  and  data  information  were  dis¬ 
played  on  the  screen. 
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simple 
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10.  Feeling  of  Control.  Your  ability  to  direct  or  control  the  activities  performed  by  the  tool. 


Comincnts; 
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vague 

weak 

unsatisfactory 

To  mo  thill  fnrtnr  in: 


high 

sufficient 

precise 

strong 

satisfactory 
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11.  Relevancy  or  System  Usefulness.  Your  perception  of  how  useful  the  system  is  as  an  aid  to  a  software 
developer. 

useless 

inadequate  _  _ 

hazy _ 

insufficient 
unsatisfactory 

To  me  this  factor  is: 

unimportant  |  |  |  |  |  |  |  ~~|  important 


useful 

adequate 

clear 

sufficient 

satisfactory 
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12.  Overall  Evaluation  of  the  System.  Your  overall  satisfaction  with  the  system. 


unsatisfied 


I  1  i  1  I  I  1 


(cont'd) 
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Evaluation  end  time 
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the  Overall  Sysl  em: 


on  evaluation  [T 


Thank  you  for  your  help. 
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Appendix  C.  The  AAARF  User’s  Manual 


The  AAARF  User’s  Manual  details  the  operation  of  the  AAARF  program.  It 
is  intended  to  be  a  stand-alone  document. 
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AAARF  User’s  Manual 


Captain  Keith  C.  Fife 


1  Introduction 

The  AFIT  Algorithm  Animation  Research  Facility  (AAARF)  is  an  interactive  algo¬ 
rithm  animation  system.  It  provides  a  means  for  visualizing  the  execution  of  algo¬ 
rithms  and  their  associated  data  structures.  AAARF  allows  the  user  to  select  the 
type  of  algorithm,  the  input  to  the  algorithm,  and  the  views  of  the  cilgorithm.  Several 
control  mechcinisms  are  provided,  including  stop,  go,  reset,  variable  speed,  single-step, 
and  break-points.  Other  features  of  AAARF  include: 

•  Multiple  Algorithm  Windows 

•  Simultaneous  Control  of  Multiple  Animations 

•  Animation  Environment  Save  and  Restore  Capability 

•  Multiple  View  Windows  within  each  Algorithm  Window 

•  Animation  Record  and  Playback 

•  Algorithm  State  Display  and  Interrogation  Capability 

•  Master  Control  Panel  for  monitoring  and  modifying  the  input,  algorithm,  view, 
and  control  parameters  to  an  algorithm  animation. 

AAARF  runs  on  Sun3^^  and  Sun4^^  workstations  using  the  SunOS^'*^  (Sun  Mi¬ 
crosystem’s  version  of  the  AT&T  UNIX^*^  operating  system)  and  the  SunView^*^ 
window-based  environment.  AAARF  is  designed  for  use  with  color  monitors. 
Monochrome  monitors  can  be  used,  but  the  displays  are  not  as  informative. 
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AAARF  has  two  types  of  users:  end-usera  who  view  and  interact  with  the  algo¬ 
rithm  animations,  and  client-programmers  who  develop  and  maintain  the  algorithms 
and  animations.  This  manual  is  primarily  for  end-users;  it  describes  how  to  use 
AAARF.  Client-progrcimmers  should  refer  to  the  AAARF  Programmer’s  Manual  [2]. 

This  manual  introduces  users  to  algorithm  animation  and  AAARF.  It  explains 
how  AAARF  can  be  used  to  explore  algorithms  in  ways  not  previously  possible.  No 
previous  experience  with  algorithm  animation  is  required;  interested  readers  may 
refer  to  The  Graphical  Representation  of  Algorithmic  Processes[3]  for  more  detailed 
information.  Though  not  necessary,  some  familiarity  with  SunOS  and  SunView  is 
helpful.  The  following  references  cire  recommended: 

•  Getting  Started  with  SunOS:  Beginner’s  Guide  [4] 

•  Setting  Up  Your  SunOS  Environment:  Beginner’s  Guide  [5] 

•  The  SunView  1  Beginner’s  Guide  [6] 

The  next  section  introduces  algorithm  animation,  describes  the  AAARF  system 
architecture,  and  presents  an  overview  of  AAARF’s  use  of  SunView.  Users  should  be 
thoroughly  familiar  with  the  concepts  presented  in  this  section  before  using  AAARF. 
Section  3  explains  how  to  start  the  AAARF  program  and  describes  the  major  com¬ 
ponents  of  the  AAARF  main  screen.  Section  4  discusses  algorithm  windows  and 
explains  how  to  start  and  control  animations.  Section  5  presents  some  exercises  to 
test  and  develop  an  understanding  of  AAARF. 
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2  Overview 


This  section  examines  the  general  architecture  of  AAARF  and  introduces  some  Sun- 
View  concepts  necessary  for  understanding  and  effectively  using  AAARF.  The  defi¬ 
nitions  that  follow  are  extracted  from  [3]  and  [1];  they  are  critical  to  an  exact  under¬ 
standing  of  the  concepts  of  this  section: 

Animation  Components  An  algorithm  animation  consists  of  three  components: 
an  input  generator,  an  algorithm,  and  one  or  more  animation  views  (see  Fig¬ 
ure  1). 


Figure  1:  Algorithm  Animation  Components 

Input  Generator  An  input  generator  is  a  procedure  which  provides  input  to  an 
algorithm;  the  input  may  be  generated  randomly,  read  from  a  file,  or  entered 
by  the  user. 

Animation  View  Animation  views  are  graphiccil  representations  of  an  algorithm’s 
execution. 

Interesting  Event  (IE)  Animation  views  are  driven  by  interesting  events  that  oc¬ 
cur  during  the  execution  of  an  algorithm.  Interesting  events  are  input  events, 
output  events,  and  state  changes  that  an  algorithm  undergoes  during  its  ex¬ 
ecution.  The  type,  quantity,  and  sequence  of  lEs  for  a  particular  algorithm 
distinguish  it  from  other  algorithms. 
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Algorithm  Classes  Algorithms  which  operate  on  identical  data  structures  and  per¬ 
form  identical  functions  are  from  the  same  algorithm  class.  The  Array  Sort  class 
includes  quick  sort,  heap  sort,  bubble  sort,  and  other  in-place  sort  algorithms. 
Algorithms  from  the  same  clciss  gener2dly  share  input  generators  and  views,  al¬ 
though  certain  views  and  input  generators  may  be  ineffective  with  particular 
algorithms.  For  instance,  the  tree  view  is  very  meaningful  for  heap  sort,  but 
neeirly  useless  for  any  other  sort. 

Parameterized  Control  User- selectable  parameters  are  associated  with  each  com¬ 
ponent.  Algorithm  parameters  affect  some  aspect  of  how  the  algorithm  executes. 
For  example,  with  a  quick  sort  algorithm,  what  partitioning  strategy  should  be 
used;  as  the  partitions  get  smaller,  at  what  point  should  another  type  of  sort 
be  used;  what  other  type  of  sort  should  be  used.  Input  Parameters  affect  the 
input  generator  —  what  seed  is  used  to  generate  a  set  of  random  numbers;  how 
“sorted”  is  a  set  of  unsorted  numbers;  what  is  the  general  form  of  a  series  of 
numbers.  View  parameters  affect  how  the  animation  is  displayed  in  the  view 
window.  For  example,  what  shape  is  associated  with  the  nodes  in  a  graph;  how 
should  an  arbitrary  graph  be  positioned. 

2.1  AAARF  Architecture 

AAARF  uses  three  levels  of  execution  linked  via  UNIX  sockets  to  animate  algorithms. 
Figure  2  shows  the  levels  of  execution. 

AAARF  Main  Process. 

AAARF’s  top-level  process  provides  the  mair  screen,  a  mechanism  for  saving  and 
restoring  animation  environments,  a  mechanism  for  controlling  multiple  algorithm 
animations  simultaneously,  and  a  meajis  for  starting  new  algorithm  animations.  This 
level  serves  as  a  high-level  manager  of  the  animation  environment. 

•  In  general,  The  AAARF  main  process  is  the  only  level  of  execution  with  which 
end-users  need  be  concerned. 

Class-Specific  Window-Based  Process. 

The  second  level  of  execution  is  the  algorithm  cl2iss-specific  window-based  process. 
The  class-specific  level  of  execution  provides  the  animation  views,  an  animation 
recorder,  a  status  display  for  interrogating  the  state  of  the  algorithm,  and  a  mcister 
control  panel  for  monitoring  and  modifying  the  parameters  that  control  the  anima¬ 
tion. 
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Figure  2:  AAARF  Levels  of  Execution 
Class-Specific  Background  Process. 

The  third  level  of  execution  is  completely  transparent  to  the  user;  this  level  imple¬ 
ments  the  input  generator  and  algorithm.  It  provides  the  window-based  level  with  the 
lEs  that  drive  the  animation.  The  actual  algorithms  being  animated  run  at  this  level. 
The  background  process  waits  with  the  next  IE  until  the  window-based  level  sends 
an  IE  request.  The  background  process  sends  the  IE  and  executes  the  algorithm  until 
the  next  IE  occurs.  It  stops  again  and  waits  for  an  IE  request  from  the  window-based 
level. 


7 


2.2  Windows 


AAARF  u'es  three  types  of  windows  to  provide  the  user  with  multiple  simultaneous 
algorithm  animations  and  multiple  views  of  each  animation.  Figure  3  shows  the  types 
of  windows  used  by  AAARF  and  their  relationship  to  one  another. 


Figure  3:  Types  of  Windows  used  by  AAARF 


AAARF  Main  Screen. 

This  is  a  full-screen  window  within  which  all  interaction  with  AAARF  is  contained. 
The  main  menu  can  be  popped  up  anywhere  on  the  AAARF  main  screen.  The  main 
screen  supports  up  to  four  algorithm  windows. 

•  The  actual  number  of  algorithm  windows  possible  is  dependent  on  the  system 
configuration,  cpu  load,  and  memory  availability. 
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Algorithm  Window. 

All  animations  take  place  within  algorithm  windows.  Every  algorithm  window  is 
associated  with  a  particular  algorithm  class.  Algorithm  windows  may  be  created  and 
destroyed  freely,  but  no  more  than  four  can  be  active  at  any  time.  Each  algorithm 
window  supports  an  animation  recorder,  a  master  control  panel,  a  status  display,  and 
up  to  four  view  windows.  Algorithm  windows  can  be  resized  and  moved  anywhere 
on  the  AAARF  screen;  they  may  overlap  one  another.  The  algorithm  menu  can  be 
popped  up  cinywhere  along  the  algorithm  window  title  bar. 


Figure  4:  Multiple  Algorithm  Windows 
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View  Windows. 


View  windows,  or  views,  are  windows  Jissociated  with  a  particular  view  of  an  algo¬ 
rithm.  Every  algorithm  window  has  at  least  one  and  as  many  as  fovr  active  view 
windows.  View  windows  can  be  resized  and  moved,  but  they  cannot  extend  beyond 
the  algorithm  window  and  they  may  not  overlap. 


Figure  5:  Multiple  Views  of  a  Single  Algorithm  Animation 
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•  Right  Button.  The  right  button  is  used  almost  exclusively  to  pop  up 
menus  (see  Section  2.4)  from  which  selections  can  be  made. 

•  Middle  Button.  The  middle  button  is  used  primarily  to  position  and  re¬ 
size  windows.  Figure  9  describes  the  procedure  for  moving  and  resizing 
windows.  The  middle  button  is  also  used  to  select  an  element  of  interest 
within  a  view  window  by  clicking  on  the  desired  element. 

•  Left  Button.  The  left  mouse  button  is  used  to  activate  panel  items  (see 
Section  2.5).  It  is  also  used  to  control  algorithm  animations;  clicking  in 
a  view  window  starts  and  stops  the  animation. 

Figure  6:  Mouse  Button  Usage 

2.3  The  Mouse 

Almost  till  interaction  with  AAARF  is  through  the  mouse.  The  mouse  is  used  to 
move  the  pointer,  or  cursor,  around  the  screen.  The  mouse  buttons  may  be  either 
clicked  (pushed  and  immediately  released)  or  depressed  (pushed  and  held  until  some 
action  is  complete).  The  function  of  the  mouse  buttons  depends  on  the  application; 
Figure  6  describes  the  mouse  button  functions.  Figure  9  explains  how  to  use  the 
mouse  to  manipulate  windows  and  panels. 

•  Just  as  you  can  type  ahead  of  the  display  with  the  keyboard,  you  can  “mouse 
ahead”  of  the  display  with  the  mouse.  Depending  on  the  CPU  load  and  the 
number  of  active  processes,  display  update  can  be  slow.  Rest  assured  the  mouse 
input  will,  eventually,  be  acknowledged.  Be  careful  when  mousing  ahead  -  you 
may  be  clicking  on  something  that  won’t  be  there  when  the  click  is  serviced. 
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•  Main  AAARF  Menu.  This  menu  is  accessed  by  pressing  the  right  mouse 
button  anywhere  on  the  AAARF  background  screen. 

•  Algorithm  Window  Menu.  This  menu  is  accessed  by  pressing  the  right 
mouse  button  einywhere  along  the  title  bau'  of  an  algorithm  window. 

•  Panel  Selectors.  These  menus  are  accessed  by  depressing  the  right  mouse 
button  on  panel  selectors  (Section  2.5)  or  panel  choice  items  (Sec¬ 
tion  2.5). 


Figure  7:  AAARF  Menus 


2.4  Menus 

AAARF  uses  menus  to  adlow  users  to  make  a  selection  from  among  several  choices. 
Users  pop  up  menus  by  depressing  the  right  mouse  button.  Generadly,  menus  remain 
visible  only  long  ais  the  right  button  remains  depressed.  While  a  menu  is  visible 
and  the  right  mouse  button  is  depressed,  moving  the  cursor  over  a  particular  menu 
entry  causes  that  entry  to  be  highlighted.  Releasing  the  right  mouse  button  with  a 
menu  item  highlighted  selects  that  menu  item.  Figure  7  describes  the  three  types  of 
menus  used  in  AAARF. 

A  menu  entry  with  a  right-aurow  indicates  that  a  pull-right  menu  is  associated 
with  that  menu  item.  Moving  the  cursor  over  the  right-arrow  exposes  the  pull-right 
menu  from  which  a  selection  can  be  made.  Usually,  the  first  item  in  a  pull-right  menu 
is  the  default  selection  for  an  item  with  a  pull-right  menu. 

2.5  Panels 

Panels  allow  users  to  interact  with  AAARF  through  a  variety  of  panel  items  such  as, 
panel  buttons,  panel  selectors,  choice  items,  aind  panel  text  items  (see  Figure  8). 

Panel  Buttons 

Panel  buttons  are  used  to  specify  an  action.  Panel  buttons  are  activated  by  clicking 
the  left  mouse  button  with  the  mouse  pointer  positioned  over  the  panel  button. 


12 


Figure  8:  Panel  Item  Examples 


Panel  Selectors 

Panel  selectors  are  used  to  pop  up  a  menu  from  which  a  particular  menu  item  can  be 
selected.  Panel  selectors  are  activated  by  depressing  the  right  mouse  button  with  the 
mouse  pointer  positioned  over  the  panel  selector.  The  mouse  button  is  released  after 
the  desired  menu  selection  is  highlighted. 

Choice  Items 

Choice  items  axe  used  to  set  options.  Choice  items  appear  as  cycle  items,  choice 
buttons,  check  boxes,  and  panel  sliders.  All  choice  items  except  the  panel  slider  can 
be  used  as  either  a  panel  button  or  a  panel  selector.  Panel  sliders  are  activated  by 
clicking  the  left  mouse  button  at  the  desired  position  on  the  slider  bar. 

Text  Items 

Text  items  allow  the  user  to  enter  data  from  the  keyboeurd.  AAARF  requires  very 
little  keyboMd  interaction. 
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•  Moving  Windows  and  Panels.  To  move  a  window,  position  the  cursor 
over  the  window’s  border.  Press  and  hold  the  middle  button  while 
repositioning  the  cursor  to  the  window’s  new  position.  Release  the 
middle  mouse  button  and  the  window  moves  to  the  new  location.  Panels 
are  moved  with  the  same  procedure. 

•  Resizing  Windows.  To  resize  a  window,  position  the  cursor  over  the 
window’s  border,  press  and  hold  the  control  key  and  the  middle  mouse 
button  while  repositioning  the  cursor  to  the  window’s  new  border  posi¬ 
tion.  Release  the  mouse  button  and  the  window  resizes.  Panels  cannot 
be  resized. 

•  Bringing  Windows  and  Panels  to  the  Front.  To  completely  expose  a 
partially  hidden  window,  click  the  left  mouse  button  on  the  hidden 
window’s  border.  The  procedure  for  panels  is  identical. 


Figure  9:  Manipulating  Windows  and  Panels 
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2.6  Alerts 


AAARF  uses  alerts  to  display  help  screens,  to  warn  users  of  internal  errors,  and 
to  get  confirmation  for  dangerous  commands.  The  user  must  click  on  one  of  the 
alert  ^n<^tons  before  input  is  be  accepted  in  any  ether  '-v’-dow  or  panel.  Figure  10 
shows  an  alert  asking  the  user  to  confirm  deletion  of  an  environment  file.  Note  that 
the  YES  button  has  a  darker  outline  than  the  NO  button.  A  button  with  a  dark 
outline  indicates  that  it  is  the  default  choice;  it  may  be  selected  with  the  mouse  or, 
alternatively,  by  hitting  the  return  key. 
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3  Getting  started 

Set  your  UNIX  path  variable  to  include  the  AAARF  executable  directory.  Your 
instructor  or  system  manager  knows  the  AAARF  directory  path.  See  [5]  for  more 
information  on  setting  UNIX  paths.  Run  AAARF  by  entering  aaarf  at  the  UNIX 
command  line  prompt. 

3.1  Welcome  Screen 

The  first  thing  you  see  is  the  AAARF  welcome  screen.  Click  the  left  mouse  button 
on  the  CONTINUE  button  to  begin  the  session. 

3.2  The  Main  Menu 

Press  and  hold  the  right  mouse  button  with  the  mouse  pointer  anywhere  on  the 
AAARF  screen  to  pop  up  the  main  menu.  Move  the  cursor  to  select  from  the  following 
choices: 

•  Iconify  AAARF 

•  New  Algorithm  Window 

•  Central  Control 

•  Environment  Control 

•  Help 

•  Kill  AAARF 
Iconify  AAARF 

This  selection  causes  AAARF  and  all  its  animations  to  become  an  icon.  The  icon  may 
be  moved  anywhere  on  the  screen.  While  in  the  icon  state,  all  animations  are  stopped 
and  most  menu  items  are  deactivated.  AAARF  is  deiconified  by  either  clicking  the 
right  mouse  button  on  the  icon  or  selecting  Deiconify  AAARF  from  the  main  menu. 

New  Algorithm  Window 

To  open  a  new  algorithm  window,  highlight  this  selection.  Move  the  cursor  over  the 
right  arrow  to  reveal  the  algorithm  claiss  menu  (see  Section  3.3).  Highlight  one  of  the 
available  classes  and  release  the  mouse  button.  Figure  11  shows  the  AAARF  main 
menu  with  the  algorithm  menu  exposed.  An  algorithm  window  with  a  default  data 
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set  cind  algorithm  appears.  Up  to  four  windows  may  be  active  simultaneously.  See 
Section  4  for  controlling  the  algorithm  window. 


AFir  Alqorit^in  Animation  Heseari:h  Facility  (AAAKF) 


Iconify  AAARi- 

Nhu  I  tlin  WtndAu 

In-P1aca  Array  Sorts  h 

Central  Control 

Trsvaraal  | 

Env1rorMi«nt  Control^ 

[  it  1  n 

Halp 

Qraatast  Connon  Danuiiinator  | 

Kill  AAARF 

■ 

Figure  11:  AAARF  Main  Menu 


Central  Control  Panel 

This  selection  causes  the  Central  Control  Panel  to  appear.  The  Centr2il  Control  Panel 
provides  a  means  to  simultaneously  control  the  animations  in  eill  open  algorithm 
windows.  See  Section  3.4  for  more  information  about  the  Central  Control  Panel. 

Environment  Control  Panel 

This  selection  causes  the  Environment  Control  Panel  to  appear.  The  Environment 
Control  Panel  provides  a  means  to  save  and  restore  AAARF  environments.  See 
Section  3.5  for  more  information  about  the  Environment  Control  Panel. 

Help 

This  selection  displays  a  help  screen  which  briefly  explains  the  fi’  iction  of  each  main 
menu  item,  how  to  use  the  mouse,  and  how  to  open  a  new  algorithm  window.  This 
help  screen  is  the  same  as  the  welcome  screen  that  appears  immediately  after  the 
program  is  evoked. 


17 


Kill  AAARF 


This  selection  ends  the  AAARF  program.  The  user  is  first  asked  to  confirm  the  kill 
command. 

3.3  Algorithm  Class  File 

AAARF  has  a  default  set  of  algorithm  classes  from  which  the  user  can  select  when 
opening  new  algorithm  windows.  The  default  classes  cire  named  in  the  .aaarf Classes 
file  located  with  the  AAARF  executable  image.  The  default  algorithm  class  file 
caji  be  overridden  by  setting  the  AAARFCLASSES  environment  variable  to  the 
filename  of  some  other  algorithm  class  file.  See  [4]  for  more  information  regarding 
UNIX  environment  variables. 

•  The  default  algorithm  class  file  suffices  for  most  end-users. 

3.4  Central  Control  Panel 

The  AAARF  Central  Control  Panel  provides  a  means  for  simultaneously  controlling 
multiple  animations  The  usual  animation  controls  provided  by  the  algorithm  window 
are  still  enabled  when  using  the  Central  Control  Panel.  Figure  4  shows  the  Central 
Control  Panel.  Use  the  right  mouse  button  to  initiate  the  following  actions: 

•  Help  Displays  a  help  screen  explaining  the  Central  Control  Pane,  unction  and 
controls. 

•  Close  Closes  the  Central  Control  Panel.  The  panel  can  be  reopened  by  selecting 
it  again  from  the  main  AAARF  menu. 

•  Go  Simultaneously  starts  animations  in  all  open  algorithm  windows.  Anima¬ 
tions  which  have  already  run  to  completion  are  not  affected.  Use  Reset  followed 
by  Go  to  restart  a  completed  animation 

•  Stop  Simultajieously  stops  animations  in  all  open  algorithm  windows.  Has  no 
affect  on  animations  that  have  already  run  to  completion 

•  Reset  Simultaneously  stops  and  resets  all  animations  to  their  respective  initial 
conditions.  Animations  may  be  running  when  the  Reset  button  is  pushed. 
There  is  no  UNDO  for  a  Reset. 
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3.5  Environment  Control  Panel 


The  AAARF  Environment  Control  Panel  provides  a  means  for  saving  the  current 
animation  environment  or  restoring  a  saved  environment.  The  environment  includes 
s,ll  ucer  o^Lionc  currently  selected:  window  size,  window  placement,  input  parame¬ 
ters,  algorithm  parameters,  and  view  parameters.  The  Environment  Control  Panel  is 
shown  in  Figure  12. 


Figure  12:  AAARF  Environment  Control  Panel 


Use  the  Path  Selector  to  select  a  directory  in  which  environments  can  be  saved 
and  restored.  The  path  selector  menu  is  activated  by  depressing  the  right  mouse 
button  on  the  Path  Selector  icon.  The  path  can  be  changed  only  by  the  Path  Sel‘*<'tor; 
there  is  no  option  to  enter  the  path  from  the  keyboard.  By  default,  the  initial  path 
is  set  to  the  user’s  current  working  directory.  The  path  can  be  initialized  to  any 
valid  directory  by  setting  the  the  AAARFENV  environment  variable  to  the  desired 
path.  Typiczdly  users  keep  2dl  their  AAARF  environments  in  a  particular  directory 
and  set  AAARFENV  to  that  directory  path.  See  [4J  for  more  information  on  setting 
environment  variables. 

•  To  save  an  AAARF  animation  environment,  the  iLser  must  have  write  privileges 
for  the  selected  directory. 
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Use  the  Environment  Selector  to  select  an  existing  environment  name,  or  en¬ 
ter  an  environment  name  from  the  keyboard.  Environment  names  consist  of  1  to 
15  alphanumeric  characters.  If  a  selected  directory  has  no  environment  files,  the 
Environment  Selector  menu  does  not  pop  up. 

When  the  environment  name  is  selected,  click  on  Save,  Restore  ,  or  Delete 
to  perform  the  desired  operation.  Only  100  saved  environments  are  permitted  per 
directory,  so  it  may  become  necessary  to  delete  unused  environments. 

•  Save  and  delete  operations  are  relatively  fast,  but  restore  operations  can  take 
several  seconds  depending  on  the  current  CPU  and  memory  load. 

The  environment  control  panel  is  not  considered  part  of  the  environment  with 
respect  to  save  and  restore  operations.  The  panel  can  be  closed  only  by  clicking  on 
the  Close  button. 
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4  Algorithm  Windows 

Animations  take  place  in  algorithm  windows.  'vVhen  an  algorithm  window  is  first 
opened,  a  default  data  set,  algorithm,  and  view  are  provided.  These  may  be  changed 
by  opening  the  master  control  panel  as  described  later  in  this  section. 

Up  to  four  algorithm  windows  can  be  active  simultaneously.  Algorithm  windows 
can  be  moved,  sized,  iconified,  or  destroyed  at  any  time.  Algorithm  windows  contain 
from  one  to  four  non-overlapping  view  windows  for  viewing  the  algorithm  in  execution. 

•  Depending  on  the  CPU  load  and  the  number  of  active  processes,  it  may  take 
several  seconds  for  a  new  algorithm  window  to  open.  Be  patient  -  give  the 
workstation  a  few  seconds  to  respond  before  trying  again. 

4.1  Algorithm  Window  Menu 

Press  and  hold  the  right  mouse  button  with  the  mouse  pointer  anywhere  on  the 
algorithm  window  title  bar  to  pop  up  the  algorithm  window  menu.  Figure  13  shows 
the  Algorithm  Window  Menu.  Move  the  cursor  to  select  from  the  following  choices: 

•  Iconify 

•  Master  Control 

•  Animation  Recorder 

•  Status  Display 

•  Help 

•  Kill 


Iconify 

This  selection  causes  the  algorithm  window  to  become  «in  icon.  While  in  the  icon 
state,  the  animation  is  stopped.  The  algorithm  window  can  be  deiconified  by  clicking 
on  the  icon  with  the  left  mouse  button  or  selecting  Deiconify  from  the  algorithm 
window  menu. 

Master  Control 

This  selection  causes  the  Master  Control  Panel  to  appeeir.  The  Ma.ster  Control  Panel 
provides  the  user  a  means  for  controlling  the  input,  view,  algorithm,  and  control 
parameters  for  the  animation.  Section  4.2  discusses  the  Master  Control  Panel  in 
detail. 
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Figure  13;  Algorithm  Window  Menu 


Animation  Recorder 

This  selection  causes  the  Animation  Recorder  to  appear.  The  animation  recorder 
provides  a  means  for  creating,  saving,  and  playing  animation  recordings.  Section  4.3 
discusses  the  Animation  Recorder. 

Status  Display 

This  selection  activates  the  algorithm  status  display  which  presents  information  re¬ 
garding  the  algorithm’s  current  state.  The  middle  mouse  button  can  be  used  to 
extract  more  detailed  information  regarding  a  particulcir  element  or  area  of  interest 
within  the  algorithm.  The  Status  Display  is  discussed  in  Section  4.4. 

Help 

This  selection  displays  a  help  message  which  describes  each  of  the  options  available 
from  the  algorithm  window  menu. 

Kill 

This  selection  permanently  closes  aii  algorithm  window. 


2? 


4.2  Master  Control  Panel 


Figure  14  shows  a  typical  Master  Control  Panel.  The  panel  is  divided  into  four  sepa¬ 
rate  but  interdependent  sections;  the  control  section,  the  input  section,  the  algorithm 
section,  and  the  view  section. 


Figure  14;  Master  Control  Panel  for  Traversal  Algorithm  Class 

Control  Section 

The  control  section  provides  panel  items  for  controlling  the  execution  of  the  algorithm 
animation.  The  Go,  Stop,  and  Reset  buttons  have  obvious  effects  on  the  animation. 
To  restart  an  animation  which  has  run  to  completion,  the  Reset  button  must  be  hit. 
An  alternative  to  these  buttons  is  clicking  the  left  mouse  button  in  any  of  the  open 
view  windows.  An  algorithm  which  has  run  to  completion  can  be  reset  by  clicking 
the  left  mouse  button  in  a  view  window. 

The  Single  Step  check  box,  the  Speed  panel  slider,  and  the  Break  Point  Se¬ 
lector  are  three  more  control  mechanisms  provided  by  the  control  section.  Activating 
single-step  mode  causes  the  animation  to  stop  after  every  IE.  Selecting  one  or  more 
break  points  causes  the  animation  to  stop  after  every  IE  which  matches  a  selected 
break  point.  The  speed  control  affects  the  execution  speed  of  the  animation;  100  is 
full  speed,  and  0  is  very  slow  speed. 


23 


Input  Section 

The  input  section  provides  parameter  controls  to  produce  a  variety  of  input  data  sets 
for  a  particular  algorithm  class.  Changes  to  input  paxcuneters  do  not  take  effect  until 
the  animation  is  Reset. 

Algorithm  Section 

This  section  provides,  as  a  minimum,  a  panel  cycle  item  for  selecting  the  algorithm 
to  be  animated.  There  may  be  optional  parameters  for  particular  algorithms.  For 
instance,  quick  sort  options  might  be  minimum  partition  size  and  the  method  for 
selecting  a  pivot  value.  Changes  to  algorithm  parameters  do  not  take  effect  until  the 
animation  is  Reset. 

View  Section 

This  section  provides,  as  a  minimum,  a  panel  selector  for  selecting  from  one  to  four 
views  of  the  animation,  and  a  p2inel  cycle  item  for  selecting  the  layout  of  the  views 
within  the  algorithm  window.  There  may  be  optional  parzuneters  for  controlling  the 
appearance  of  the  view,  such  as  the  representation  or  size  of  nodes  in  a  binary  tree. 
Changes  to  view  parameters  take  effect  immediately. 

4.3  Animation  Recorder 

Each  algorithm  window  supports  an  einimation  recorder  for  recording  and  playing 
back  computationally  intensive  animations.  Figure  15  shows  the  AAARF  animation 
recorder.  The  recorder  also  provides  a  convenient  means  for  saving  a  particular  set  of 
algorithm  parameters.  Currently  the  recorder  does  not  support  playback  in  reverse. 

The  recorder  is  2dways  in  one  of  three  states:  OFF,  RECORD,  or  PLAY.  The 
algorithm  window  title  bar  reflects  the  current  state  of  the  recorder.  Depending  on 
the  current  recorder  state,  some  operations  may  not  be  possible  or  allowed.  Warnings 
are  issued  before  any  recording  is  erased. 

The  Help  button  activates  a  brief  help  screen  explaining  how  to  use  the  animation 
recorder.  The  recorder  can  be  closed  only  by  clicking  on  the  Close  button. 
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Figure  15:  AAARF  Animation  Recorder 


Recording 

To  record  an  animation,  click  on  the  RECORD  button.  The  animation  resets  us¬ 
ing  the  currently  selected  parameters,  and  the  algorithm  window  title  bar  displays 
“****  RECORDING  ****”.  Control  the  animation  as  usual.  When  the  animation 
is  finished,  the  recorder  switches  to  PLAY  mode  and  the  algorithm  window  title  bar 
displays  “****  PLAYBACK  ****”.  The  recording  caji  now  be  saved  or  played  back. 

•  Control  commands  are  not  saved;  only  the  interesting  events  are  recorded. 
Playback 

Before  a  recording  can  be  played,  it  must  be  recorded.  Recordings  can  be  saved, 
reloaded,  and  played;  or  just  recorded  and  played  without  saving.  Once  a  recording 
is  loaded  into  the  recorder,  the  algorithm  window  title  bar  displays  “***♦  PLAY¬ 
BACK  *♦**”.  Playback  can  be  started  in  several  ways:  the  FORWARD  button 
on  the  recorder,  the  GO  button  on  the  Master  Control  Panel,  the  GO  button  on 
the  Central  Control  Panel,  or  by  clicking  the  left  mouse  button  in  a  view  window. 
Since  only  the  interesting  events  are  recorded,  the  view  parameters  can  be  changed 
while  the  recording  is  playing  back;  likewise  the  recording  can  be  controlled  just  like 
a  “normal”  animation. 
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File  Functions 

Use  the  Path  Selector  to  select  a  directory  in  which  recordings  can  be  saved  and 
restored.  The  path  selector  menu  is  activated  by  depressing  the  right  mouse  button 
on  the  Path  Selector  icon.  The  path  can  be  changed  only  by  the  Path  Selector; 
there  is  no  option  to  enter  the  path  from  the  keyboard.  By  default,  the  initial  path 
is  set  to  the  user’s  current  working  directory.  The  path  can  be  initialized  to  any 
valid  directory  by  setting  the  the  AAARFREC  environment  variable  to  the  desired 
recording  directory.  Typically,  users  keep  all  their  AAARF  recordings  in  a  particular 
directory,  possibly  partitioning  it  into  subdirectories  corresponding  to  each  algorithm 
class.  The  AAARFREC  environment  variable  is  set  to  the  parent  directory  name. 
See  [4]  for  more  information  on  setting  environment  variables. 

•  To  save  an  AAARF  animation  recording,  the  user  must  have  write  privileges 
for  the  selected  directory. 

Use  the  Recording  Selector  to  select  cm  existing  recording  ncime,  or  enter  an 
recording  name  from  the  keyboard.  Recording  names  consist  of  1  to  15  alphanumeric 
characters.  If  a  selected  directory  heis  no  recording  files,  the  Recording  Selector 
menu  does  not  pop  up. 

When  the  recording  name  is  selected,  click  on  Save,  Restore,  or  Delete  to 
perform  the  desired  operation.  Only  100  saved  recordings  are  permitted  per  directory, 
so  it  may  become  necessary  to  delete  unused  recordings. 

Loading  a  recording  sets  the  input,  algorithm,  and  control  parameters  to  those  as¬ 
sociated  with  the  recording;  the  view  parauneters  are  not  affected.  Saving  a  recording 
resets  all  parameters  to  their  state  at  the  beginning  of  the  recording. 
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4.4  Status  Display 

Each  cilgorithm  window  supports  a  status  display  which  provides  information  relating 
to  the  current  state  of  the  cilgorithm.  Figure  16  shows  a  typical  Status  Display. 
The  information  and  format  may  be  different  for  each  algorithm  class.  Users  can 
interrogate  the  animation  regeirding  specific  aspects  of  the  algorithm,  such  as  a  tree 
node  or  array  element  state  by  clicking  the  middle  mouse  button  in  a  view  window 
on  a  pcirticulcir  element  of  interest. 

The  Help  and  Close  buttons  perform  their  usual  functions. 


A1  I  r  A  Iqtir' i  Mill  An  iiiia  t  i  Ilf  I  KHsear  i  h  lari  illy  (AAAKl  ) 


[  HELP  1  AAAHF  AnlMtlni  Status  Panel  |  CLOSE  ] 

Element  of  Intereet  -  9 
State  -  MOVING 

Current  value  of  this  element  -  1 
Number  of  moves  for  this  element  -  4 
Comparisons  against  this  element  -  5 

Algorithm  State 

Moving  element  9  to  position  10 
TOTAL  MOVES  -  58 
TOTAL  COMPARES  -  70 


Figure  16:  Status  Display  for  ArraySort  Algorithm  Class 
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5  Exercises 


This  section  presents  exercises  to  test  and  develop  your  skill  using  AAARF.  The 
first  exercise  directs  you  through  aa  entire  AAARF  session.  The  remaining  exercises 
require  a  little  more  thought. 


Problem  1.  Compare  the  performcince  of  Straight  Selection  Sort  to  Straight 
Insertion  Sort  for  sorting  an  array  of  25  numbers.  The  numbers  are  already  sorted, 
but  in  reverse  order.  Record  the  einimation  of  the  fastest  algorithm.  How  many  total 
moves  were  required?  How  many  comparisons? 

1.  Startup  AAARF  by  typing  aaarf  at  the  UNIX  command  line  prompt. 

2.  Click  on  CONTINUE  to  close  the  welcome  screen. 

3.  Open  two  ArraySort  algorithm  windows,  by  popping  up  the  main  menu,  se¬ 
lecting  the  New  Algorithm  Window  item,  eind  then  selecting  Array  Sorts 
from  the  pull-right  algorithm  menu. 

4.  Open  the  Master  Control  Panels  for  both  windows. 

5.  Select  Straight  Insertion  Sort  for  one  window  and  Straight  Selection  Sort  for  the 
other. 

6.  Select  25  elements,  100%  sorted,  and  Inverted  order  for  both  windows. 

7.  Select  stacked  Sticks,  Moves,  and  Compaires  views  for  both  windows. 

8.  Set  speed  to  100%  in  both  windows. 

9.  Close  both  Master  Control  Panels. 

10.  Open  the  Central  Control  Panel. 

11.  Arrange  the  algorithm  windows  and  Central  Control  Panel  such  that  the  algo¬ 
rithm  windows  are  the  same  size,  no  windows  are  hidden,  and  both  animations 
are  easy  to  see  and  compare.  Figure  17  shows  a  possible  arrangement. 

12.  Open  the  Environment  Control  Panel.  Select  a  directory  and  an  environment 
name,  and  save  this  environment. 

13.  Close  the  Environment  Control  Panel. 
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Figure  17:  Possible  Window  Arremgement  for  Exercise  1. 


Using  the  Central  Control  Panel,  Reset  both  algorithm  windows. 

Using  the  Central  Control  Panel,  steirt  both  algorithms  by  clicking  on  Go. 

Determine  which  algorithm  is  fastest  £ind  close  (Kill)  the  other  window. 

Open  the  Status  Display  for  the  fastest  algorithm  window  and  note  the  total 
comparisons  and  moves. 

Close  the  status  display. 

Open  the  Animation  Recorder. 

Hit  the  Record  button,  then  hit  Forward. 

When  the  animation  is  finished,  save  the  recording. 

Open  the  MEister  Control  Panel  and  change  the  parameter  settings.  Hit  the 
Reset  button. 

Load  the  recording  that  was  just  saved.  Notice  that  the  parameter  settings 
reset  to  those  associated  with  the  recording. 
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24.  Playback  the  recording. 

25.  Close  the  Recorder  and  Kill  the  algorithm  window. 

26.  Pop  up  the  AAARF  main  menu  zmd  Kill  AAARF. 

Problem  2.  Open  three  Traversal  algorithm  windows.  For  each  algorithm 
window,  select  26  eis  the  tree  size,  set  the  control  to  single  step,  and  select  both  the 
tree  and  list  views,  but  let  the  tree  view  dominate  the  algorithm  window.  Select  a 
different  algorithm  for  each  window.  Arrange  and  size  the  algorithm  windows  so  that 
all  three  can  easily  be  seen.  Open  the  Central  Control  Panel  and  run  the  animations 
simultaineously.  Save  the  environment.  Which  algorithm  traverses  the  entire  tree 
first?  Which  is  last? 


Problem  3.  A  program  module  to  maintain  a  sorted  array  of  numbers  must 
be  developed  for  the  B-10  bomber  automatic  pilot  software.  The  array  of  numbers  is 
built  by  another  module  from  five  other  sorted  lists  of  numbers.  Sometimes  the  five 
sub-list:  "orted  in  ascending  order,  other  times  in  descending  order.  The  sub-lists 

are  always  composed  of  at  least  10  elements.  Use  AAARF  to  determine  the  best 
sort  algorithm  for  this  program  module.  Create  an  AAARF  environment  to  compare 
the  top  two  sort  algorithms.  Save  the  animation  environment.  Which  algorithm  is 
probably  best? 


30 


References 


[1]  Brown,  Marc  H.  Algorithm  Animation.  Cambridge,  Massachusetts:  The  MIT 
Press,  1987. 

[2]  Fife,  Keith  C.  “The  AAARF  Programmer’s  Guide.”  Air  Force  Institute  of  Tech¬ 
nology,  November  1989. 

[3]  Fife,  Keith  C.  Graphical  Representation  of  Algorithmic  Processes.  MS  thesis,  Air 
Force  Institute  of  Technology,  1989. 

[4]  Sun  Microsystems.  Getting  Started  with  SunOS:  Beginner’s  Guide,  1988.  SunOS 
Technical  Documentation. 

[5]  Sun  Microsystems.  Setting  Up  Your  SunOS  Environment:  Beginner’s  Guide, 
1988.  SunOS  Technical  Documentation. 

[6]  Sun  Microsystems.  SunViewl  Beginner’s  Guide,  1988.  SunOS  Technical  Docu¬ 
mentation. 


31 


Appendix  D.  The  AAARF  Programmer’s  Guide 


The  AAARF  Programmer’s  Guide  details  the  implementation  of  the  AAARF 
program.  It  provides  a  guide  for  developing  new  animations  and  maintaining  the 
AAARF  program.  It  is  intended  to  be  a  stand-alone  document. 


D-1 


AAARF  Programmer’s  Guide 


Keith  Carson  Fife 
Captain,  USAF 

Department  of  Electrical  and  Computer  Engineering 
School  of  Engineering 
Air  Force  Institute  of  Technology 
Wright-Patterson  Air  Force  Base,  Ohio  45432 


December,  1989 


Contents 


1  Introduction  4 

2  Overview  6 

2.1  Algorithm  Animation  Concepts  and  Definitions  .  6 

2.2  AAARF  Architecture .  9 

2.3  Windows .  11 

2.4  AAARF  Directory  Structure .  13 

2.5  SunView .  14 

2.6  Program  Documentation .  16 

2.7  Client- Progiammer  Tasks  .  17 

3  The  AAARF  Main  Process  18 

3.1  aaarf.c .  19 

3.2  aaarfMenu.c .  20 

3.3  aaarfControl.c .  21 

3.4  aaarfEnvironment.c .  22 

3.5  aaarfWindows.c .  23 

4  Class-Common  Library  25 

4.1  aciarfCommon.c .  32 

4.2  aaarfMaster.c .  34 

4.3  aaarfRecorder.c .  35 

4.4  aaarfViews.c .  37 

4.5  aaarfUtilities.c .  38 

5  Class-Specific  Functions  39 

5.1  Creating  a  Working  Directory .  40 

5.2  Testing  a  New  Algorithm  Class  .  40 

5.3  General  Requirements  .  41 

5.4  Class- Specific  Header  File .  43 

5.5  Input  Functions .  45 

5.6  Algorithm  Functions .  45 

5.7  View  Functions .  46 

5.8  Status  Functions  .  47 

5.9  Control  Functions .  48 

6  AAARF  Projects  49 


1 


List  of  Figures 


1  Algorithm  Animation  Components  .  7 

2  Algorithm  Animation  System .  8 

3  AAARF  Levels  of  Execution .  9 

4  AAARF  Windows .  11 

5  Multiple  Algorithm  Windows  .  12 

6  Multiple  Views  within  an  Algorithm  Window  .  13 

7  AAARF  Directory  Structure .  14 

8  SunView  Notifier  Model  [13:23]  .  15 

9  Creating  a  Working  Directory  for  the  Bin  Packing  Class  .  40 

10  Background  Process  Structure .  42 


List  of  Tables 


1  Module  Header  Information .  16 

2  Function  Header  Information  .  17 

3  Function  Prototypes  for  aaarf.c .  19 

4  Function  Prototypes  for  aaarfMtnu.c .  20 

5  Function  Prototypes  for  aaarf Control,  c .  21 

6  Function  prototypes  for  aaarf  Environment,  c .  22 

7  Function  Prototypes  for  aaar /Windows,  c .  24 

8  aaarfWindows.c  Data  Structures .  24 

9  aaarf  Defines. h .  27 

10  aaarf  IP  C.h .  28 

11  commonDe fines. h  (1  of  2)  29 

12  commcnDefines.h  (2  of  2)  30 

13  classCommon.h .  31 

14  Function  Prototypes  for  aaarfCommon.c .  33 

15  Function  Prototypes  for  aaarfMaster.c .  34 

16  Function  Prototypes  for  aaarf  Recorder,  c .  36 

17  aaar/i?ecorder.c  Data  Structures .  36 

18  Function  Prototypes  for  aaarfViews.c .  37 

19  Function  Prototypes  for  aaarf  Utilities,  c .  38 

20  Samole  classSpecific.h  from  the  AriaySort  Cleiss .  44 

21  Required  Input  Functions  .  45 

22  Required  Algorithm  Functions .  45 

23  Required  View  Functions .  46 

24  Required  Status  Functions .  47 

25  Required  Control  Functions .  48 


7 


AAARF  Programmer’s  Guide 

Captain  Keith  C.  Fife 


1  Introduction 

The  AFIT  Algorithm  Animation  Research  Facility  (AAARF)  is  an  interactive  algo¬ 
rithm  animation  system.  It  provides  a  means  for  visualizing  the  execution  of  algo¬ 
rithms  and  their  associated  data  structures.  AAARF  allows  the  user  to  select  the 
type  of  algorithm,  the  input  to  the  algorithm,  and  the  views  of  the  algorithm.  Several 
control  mechanisms  are  provided,  including  stop,  go,  reset,  variable  speed,  single-step, 
and  break-points.  Other  features  of  AAARF  include: 

•  Multiple  Algorithm  Windows 

•  Simultaneous  Control  of  Multiple  Animations 

•  Animation  Environment  Save  and  Restore  Capability 

•  Multiple  View  Windows  within  each  Algorithm  Window 

•  Animation  Record  and  Playback 

•  Algorithm  State  Display  and  Interrogation  Capability 

•  Master  Control  Panel  for  monitoring  and  modifying  the  input,  algorithm,  view, 
and  control  oarameters  to  an  algorithm  animation. 

AAARF  runs  on  Sun3^^  and  Sun4^*^  workstations  using  SunOS^^  (Sun  Mi¬ 
crosystem’s  version  of  the  AT&T  UNIX^*^  operating  system)  and  the  SunView^^ 
window-bcised  environment.  AAARF  is  designed  for  use  with  color  monitors.  It  can 
be  used  with  monochrome  monitors,  but  the  displays  are  not  as  informative.  AAARF 
is  written  in  the  C  programming  language. 
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AAARF  has  two  types  of  users:  end-users  who  view  and  interact  with  the  algo¬ 
rithm  animations,  and  client-programmers  who  develop  and  maintain  the  AAARF 
program  and  its  algorithm  animations.  Th>s  manual  is  intended  for  client- 
programmers.  It  describes  the  overall  AAARF  implementation  and  provides  a 
guide  for  creating  new  algorithm  animations  for  AAARF.  End-users  should  refer  to 
the  AAARF  User’s  Manual  [2]. 

Client-programmers  should  have  experience  with  AAARF  as  end-users  and  be  fa¬ 
miliar  with  the  terms  and  concepts  associated  with  algorithm  animation.  Experience 
with  C,  UNIX,  and  SunView  is  assumed.  The  following  references  are  recommended: 

•  Getting  Started  with  SunOS:  Beginner’s  Guide  [8] 

•  Setting  Up  Your  SunOS  Environment:  Beginner’s  Guide  [11] 

•  The  SunView  1  Beginner’s  Guide  [12] 

•  The  C  Programming  Language  [5] 

•  C  Programmer’s  Guide  [7] 

•  Network  Programming  [9] 

•  SunViewl  Programmer’s  Guide  [13] 

•  Pixrect  Reference  Guide  [10] 

•  Algorithm  Animation  [1] 

•  The  Graphical  Representation  of  Algorithmic  Processes  [3] 

The  next  section  presents  an  overview  of  AAARF  and  an  introduction  to  terms 
and  concepts  associated  with  algorithm  animation;  this  is  the  starting  point  for  new 
AAARF  programmers.  After  gaining  some  familiarity  with  AAARF,  this  section 
may  be  used  only  as  a  reference.  Section  3  discusses  the  AAARF  main  process.  This 
section  is  intended  piimarily  cis  a  maintenance  guide  for  the  AAARF  main  process; 
however,  it  is  also  recommended  reading  for  programmers  who  cire  creating  new  al¬ 
gorithm  animations.  Section  4  introduces  the  animation  level  of  AAARF.  Aspects  of 
AAARF  algorithm  animations  common  to  all  algorithm  classes  are  presented  here. 
Section  5  discusses  the  class-specific  aspects  of  creating  algorithm  animations.  Sec¬ 
tions  4  and  5  are  essenl  ial  references  for  the  development  of  new  algorithm  animations. 
Section  6  presents  some  ideas  and  suggestions  for  AAARF  extensions  and  program¬ 
ming  projects. 
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2  Overview 


This  section  presents  an  introduction  to  several  topics  of  interest  to  AAARF  pro¬ 
grammers  and  animation  developers.  It  outlines  some  basic  concepts  of  algorithm 
animation  and  presents  an  overview  of  the  AAARF  system  architecture.  The  Sun- 
View  Notifier  and  program  documentation  are  also  discussed.  It  is  important  to  un¬ 
derstand  the  concepts  presented  in  this  section  before  beginning  to  develop  AAARF 
applications.  See  the  references  listed  iu  Section  1  for  more  detailed  presentations. 

2.1  Algorithm  Animation  Concepts  and  Definitions 

These  concepts,  extracted  from  [3]  and  [1],  are  critical  for  maintaining  AAARF  and 
its  algorithm  animations. 

Animation  Components  An  algorithm  animation  consists  of  three  components: 
an  input  generator,  an  algorithm,  and  one  or  mere  animation  views  (see  Fig¬ 
ure  1). 

Input  Generator  An  input  generator  is  a  procedure  which  provides  input  to  an 
algorithm;  the  input  may  be  generated  randomly,  read  from  a  file,  or  entered 
by  the  user. 

Animation  View  Animation  views  are  graphical  representations  of  an  algorithm’s 
execution.  The  view  refers  to  both  the  graphical  representation  and  the  software 
that  generates  the  view. 

Interesting  Event  (IE)  Animation  views  are  driven  by  interesting  events  that  oc¬ 
cur  during  the  execution  of  au  algorithm.  Interesting  events  are  input  events, 
output  events,  and  state  changes  that  an  algorithm  undergoes  during  its  ex¬ 
ecution.  The  type,  quantity,  and  sequence  of  lEs  for  a  particular  algorithm 
distinguish  it  from  other  algorithms. 

Algorithm  Class  Algorithms  which  operate  on  identical  data  structures  and  per¬ 
form  identical  functions  are  from  the  same  algorithm  class.  The  Array  Sort  class 
includes  quick  sort,  heap  sort,  bubble  sort,  and  other  la-place  sort  algorithms. 
Algorithms  from  the  same  class  generally  share  input  generators  and  views,  al¬ 
though  certain  views  and  input  generators  may  be  ineffective  with  particular 
algorithms.  For  inst£ince,  the  tree  view  is  very  meaningful  for  heap  sort,  but 
nearly  useless  for  any  other  sort. 

Algorithm  Animation  System  Model  The  elements  of  an  algorithm  animation 
system  are  depicted  in  Figure  2  and  include  the  environment  manager,  compo¬ 
nent  library,  and  library  manager. 
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View  1 


Figure  1:  Algorithm  Animation  Components 

Environment  Manager  The  environment  manager  is  the  process  with  which  end- 
users  interact  to  select,  control,  and  view  algorithm  animations.  The  environ¬ 
ment  manager  supports  multiple  algorithm  animations  and  provides  a  means 
for  controlling  their  execution. 

Component  Library  The  component  librewy  is  a  collection  of  algorithm  compo¬ 
nents  arranged  by  algorithm  cleiss.  The  environment  manager  calls  routines 
from  the  component  libr€U'y. 

Library  Manager  The  library  manager  is  the  process  with  which  client- 
programmers  interact  to  maintain  the  component  library.  The  library  manager 
provides  a  means  to  add  and  delete  classes  and  to  create,  modify,  or  delete 
algorithms,  input  generators,  and  views  within  algorithm  classes.  Although  the 
environment  manager  uses  the  component  library  directly,  changes  made  by 
the  library  manager  should  not  affect  the  environment  manager.  The  modified 
components  should  be  immediately  ready  for  use  by  the  environment  manager. 

Parameterized  Control  User-selectable  parameters  are  associated  with  each  com¬ 
ponent.  Algorithm  parameters  affect  some  aspect  of  how  the  algorithm  executes. 
For  example,  with  a  quick  sort  algorithm,  what  partitioning  strategy  should  be 
used;  eis  the  partitions  get  smaller,  at  what  point  should  another  type  of  sort 
be  used;  what  other  type  of  sort  should  be  used.  Input  parameters  affect  the 
input  generator  -  what  seed  is  used  to  generate  a  set  of  random  numbers;  how 


1 

i 


7 


8 


“sorted”  is  a  set  of  unsorted  numbers;  what  is  the  general  form  of  a  series  of 
numbers.  View  parameters  affect  how  the  animation  is  displayed  in  the  view 
window.  For  example,  what  shape  is  associated  with  the  nodes  in  a  graph;  how 
should  an  arbitrary  graph  be  positioned. 

2.2  AAARF  Architecture 

AAARF  uses  three  levels  of  execution  linked  via  UNIX  sockets  [9:191-217]  to  imple¬ 
ment  the  algorithm  animation  system  model.  Sockets  are  the  interprocess  communi¬ 
cation  mechanism  provided  by  the  UNIX  operating  system.  Figure  3  shows  the  levels 
of  execution. 


Figure  3:  AAARF  Levels  of  Execution 
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The  AAARF  Main  Process 

AAARF’s  top-level  process  acts  as  the  environment  manager.  It  provides  the  main 
screen,  a  mechanism  for  saving  and  restoring  animation  environments,  a  mechanism 
for  controlling  multiple  algorithm  animations  simultaneously,  and  a  means  for  starting 
new  algorithm  animations. 

•  In  general,  the  AAARF  main  process  requires  the  least  attention  from  client- 
programmers. 

The  Class-Specific  Window-Based  Process 

The  second  level  of  execution  is  the  class-specific  window-based  process.  The  window- 
based  level  of  execution  provides  the  animation  views,  an  animation  recorder,  a  status 
display  for  interrogating  the  state  of  the  algorithm,  and  a  master  control  panel  for 
monitoring  and  modifying  the  parameters  that  cdfect  the  animation.  The  view  com¬ 
ponent  of  Figure  2  is  implemented  at  this  level. 

The  Class-Specific  Background  Process 

The  third  level  of  execution  is  transparent  to  the  user;  this  level  is  the  implementation 
of  the  input  generator  and  algorithm  components  of  the  algorithm  animation  system 
model  (Figure  2).  It  provides  the  window-based  level  with  the  IBs  that  drive  the 
animation.  The  background  process  waits  with  an  IE  until  the  window-based  level 
sends  an  IE  request.  The  background  process  sends  the  IE,  then  resumes  execution 
of  the  algorithm.  At  the  next  IE,  the  background  process  again  stops  and  waits  for 
an  IE  request  from  the  window- based  process. 
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2.3  Windows 

AAARF  uses  three  types  of  windows  to  provide  the  user  with  multiple  simultaneous 
algorithm  einimations  cind  multiple  views  of  each  animation.  Figure  4  shows  the  types 
of  windows  used  by  AAARF  and  their  relationship  to  one  another. 


Figure  4:  AAARF  Windows 


AAARF  Main  Screen 

This  is  a  full-screen  window  within  which  ail  interaction  with  AAARF  is  contained. 
The  m^un  screen  currently  supports  up  to  four  algorithm  windows. 

•  The  actual  number  of  algorithm  windows  possible  is  dependent  on  the  system 
configuration,  cpu  load,  and  memory  availability. 


Algorithm  Window 

All  animations  take  place  within  algorithm  windows.  Every  algorithm  window  is 
associated  with  a  particular  algorithm  class.  Algorithm  windows  may  be  created 
and  destroyed  at  any  time,  but  no  more  than  four  can  be  active  at  any  time.  Each 
algorithm  window  supports  an  animation  recorder,  a  master  control  panel,  a  status 
display,  and  up  to  four  view  windows.  Algorithm  windows  can  be  resized  and  moved 
anywhere  on  the  AAARF  screen;  they  may  overlap  one  another. 


Figure  5:  Multiple  Algorithm  Windows 


View  Window 


View  windows,  or  views,  are  windows  associated  with  a  particular  view  of  an  algo¬ 
rithm.  Every  algorithm  window  has  at  least  one  and  as  many  as  four  active  view 
windows.  View  windows  can  be  resized  and  moved,  but  they  cannot  grow  outside  of 
the  algorithm  window  and  they  may  not  overlap. 


Figure  6:  Multiple  Views  within  an  Algorithm  Window 


2.4  AAARF  Directory  Structure 

The  AAARF  directory  structure  consists  of  the  aaor/ parent  directory  and  four  sub¬ 
directories;  bin,  main,  lib,  and  icons.  Any  number  of  class  subdirectories  may  also  be 
included,  but  there  is  no  requirement  for  them  to  exist  within  the  aaarf  directory. 

The  bin  subdirectory  contains  the  aaarf  executable  image  and  the  default  AAARF 
class  file  {.aaarf Classes).  The  AAARF  classes  file  lists  the  available  algorithm  classes 
and  the  name  of  the  executable  file  for  each  class.  Section  3.2  addresses  the  AAARF 
class  file  in  more  detail.  Typically,  algorithm  clciss  executables  are  also  stored  in  bin, 
but  it  is  not  a  requirement. 

The  main  subdirectory  contains  source  code  for  the  main  AAARF  process.  Sec¬ 
tion  3  discusses  the  files  in  this  subdirectory. 
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Figure  7:  AAARF  Directory  Structure 


The  lib  subdirectory  contains  source  code  common  to  all  algorithm  classes.  Client- 
programmers  use  this  source  code  eis  a  starting  point  for  building  new  algorithm 
animations.  Section  4  discusses  the  files  in  this  subdirectory. 

The  icons  subdirectory  contains  the  icons  used  by  AAARF. 

If  class  subdirectories  exist,  they  contcun  the  source  code  for  their  respective  al¬ 
gorithm  class  executables.  Section  5  discusses  the  functions  required  for  creating  an 
algorithm  animation. 


2.5  SunView 

SunView  is  an  object-oriented  system  that  provides  a  set  of  visual  building  blocks  for 
assembling  user  interfaces.  SunView  objects  include  windows,  pointers,  icons,  menus, 
alerts,  panel  items,  and  scrollbars.  AAARF  makes  extensive  use  of  SunView  objects; 
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only  the  background  process  does  not  use  SunView. 

SunView  is  a  notification-based  system.  The  Notifier  acts  as  the  controlling  entity 
within  an  application,  reading  UNIX  input  from  the  kernel,  and  formatting  it  into 
higher-level  events,  which  it  distributes  to  the  appropriate  SunView  objects.  The 
Notifier  notifies,  or  calls,  various  procedures  which  the  application  has  previously 
registered  with  the  Notifier.  These  procedures  are  called  notify  procedures.  The 
SunView  Notifier  model  is  shown  in  Figure  8. 


Figure  8:  SunView  Notifier  Model  [13:23] 
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2.6  Program  Documentation 

The  existing  source  code  is  fully  documented  in  accordance  with  AFIT  System  Devel¬ 
opment  Documentation  Guidelines  and  Standards  [4].  Most  functions  are  less  than 
one  page  long  and  most  modules  contain  less  than  ten  functions.  The  existing  AAARF 
source  code  should  be  used  along  with  this  manual  in  developing  new  animations. 


•  FILE  :  The  module  name  (UNIX  file  name) 

•  PROJECT  ;  AFIT  Algorithm  Animation  Research  Facility  (AAARF) 

•  DATE  :  Date  of  current  version  number 

•  VERSION  :  Current  version  number 

•  AUTHOR  :  Person  or  persons  who  are  responsible  for  the  module. 

•  DESCRIPTION  ;  Description  of  the  module’s  function. 

•  FUNCTIONS  :  List  of  functiojs  implemented  in  the  module. 

•  REFERENCES  :  References  which  could  help  explain  what’s  happening 
in  the  module. 

•  HISTORY  :  List  of  major  changes  to  the  module 


Table  1;  Module  Header  Information 
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•  FUNCTION  NAME  ;  Name  of  thf>  function.  I 

•  FUNCTION  NUMBER  :  Function’s  number  within  ihis  module.  ! 

•  VERSION  NUMBER  :  Current  version  number. 

•  DATE  :  Date  of  current  version  number. 

•  DESCRIPTION  :  Detailed  description  of  what  the  function  does.  j 

•  INPUT  PARAMETERS  :  List  and  description  of  input  parameters. 

•  OUTPUT  PARAMETERS  :  List  and  description  cf  output  parameters. 

•  GLOBALS  USED  :  List  of  global  variables  used. 

I  •  GLOBALS  AFFECTED  :  List  of  global  variables  changed. 

•  FUNCTIONS  CALLED  ;  List  of  functions  called. 

•  HISTORY;  List  of  major  changes  to  the  function. 

I _ 

Table  2:  Function  Header  Information 

2.7  Client-Programmer  Tasks 

Client-programmers  are  most  frequently  concerned  with  the  window-based  level  and 
its  corresponding  background  process.  Undoubtedly,  their  most  difficult  task  is  iden¬ 
tifying  lEs  and  'developing  meaningful  views  to  represent  ther-  Other  typical  tasks 
include: 

•  Adding  new  input  generators  and  modifying  existing  input  generators  for  an 
existing  algorithm  class. 

•  Adding  new  algorithms  and  modifying  existing  algorithms  for  an  existing  algo¬ 
rithm  class. 

•  .Adulng  new  views  and  modifying  existing  views  for  an  existing  algorithm  class. 

•  Developing  new  algorithm  classes. 

•  Improving  and  extending  capabilities  of  main  AA/  RF  process. 
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5  The  AAARF  Main  Process 


The  AAARF  main  process  is  not  associated  with  any  particular  algorithm  animation, 
but  provides  an  enviionment  in  which  any  algorithm  animation  can  be  controlled.  The 
AAARF  main  process  ’.s  stand-alone,  but  without  animation  pro^'*<!=»s  run,  it  it 
not  very  interesting.  The  source  code  for  the  AAARF  main  process  is  contained  in 
the  main  subdirectory  and  consists  of  the  following  files: 

•  aaarf.c  Creates  the  main  AAARF  screen  and  displays  the  welcome  screen. 

•  aaarf Control,  c  Creates  and  maintains  the  Central  Animation  Controller. 

•  aaarf  Environment,  c  Creates  and  maintains  the  AAARF  Environment  Control 
Panel. 

•  aaarf  Menu,  c  Creates  and  maintains  the  AAAR.F  main  menu. 

•  aaarfWindows.c  Opens  and  closes  algorithm  windows.  Maintains  accounting 
information  regarding  open  algorithm  windows. 

Each  module  has  a  corresponding  header  file  in  which  the  module’s  functions, 
giobals,  and  data  structures  are  declared.  The  following  sections  discuss  each  of  the 
five  modules. 
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3.1  aaarf.c 


This  is  the  top  level  module  for  the  AAARF  main  process.  It  creates  the  AAARF 
main  screen  and  calls  functions  from  the  other  modules  to  create  their  respective 
contributions  to  AAARF.  Table  3  lists  the  functions  included  in  aaarf.c. 

The  aaarf EventDispatchO  function  interposes  user  input  to  AAA’~,  F  such  that: 

•  The  cursor’s  screen  position  is  saved  when  the  right  mouse  button  is  depressed. 
Windows  and  panels  appear  at  the  most  recently  recorded  cursor  position. 

•  If  AAARF  is  iconic,  the  left  mouse  button  deiconifles  AAARF.  Otherwise  the 
left  mouse  button  is  ignored,  thus  disabling  its  usual  function  of  popping  and 
pushing  windows. 

•  If  AAARF  is  iconic,  the  middle  mouse  button  is  used  to  move  the  icon.  Other¬ 
wise,  the  middle  button  is  ignored,  forcing  the  »AARF  main  screen  to  be  either 
full-size  or  iconic.  This  eliminates  any  problems  with  hidden  o’"  lost  algorithm 
windows  among  other  application  windows. 

•  Ignore  ACTION  keys.  Forces  use  of  mouse  and  eliminates  another  way  to  loose 
windows. 

A  polling  timer  is  associated  with  aaarf  SbowWelcomeMessageO  in  mainO .  When 
windowjnain-LoopO  is  entered,  the  Notifier  calls  aaarf ShowWelcomeMessageO .  It 
displays  the  AAARF  help  screen  and  disables  its  polling  timer.  Occasionally,  on  a 
Sun3,  the  help  screen  is  displayed  before  the  AAARF  main  screen  -  the  solution  has 
been  to  set  the  polling  timer  for  a  longer  interval. 


int  main(int,  char*' ) 

Notify -Value  aaarfEventDispatch(Frame,  Event,  Notify -arg.  Notify  .event -type) 
Notify.value  aaarfShowWelcomeMessage(Notify .client,  int) 

’  id  aaarfHelpO 


Table  3:  Function  Prototypes  for  aaarf.c 
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3.2  aaarfMenu.c 


This  module  creates  the  main  menu.  In  doing  so,  it  registers  a  notify  .procedure  for 
each  menu  item  with  the  Notifier.  When  a  menu  item  is  selected,  the  Notifier  evokes 
the  appropriate  function.  Table  4  lists  the  functions  implemented  in  aaarfMenu.c. 

At  stcirtup,  mainO  calls  setupMainMenuO  which  looks  for  the  AAARFCLASSES 
environment  variable.  If  it’s  set  to  a  valid  AAARF  class  file,  that  file  is  used  to  gener¬ 
ate  the  algorithm  class  menu.  Otherwise,  the  default  AAARF  class  file,  .aaarfClasses, 
is  used. 

The  AAARF  class  file  contains  a  list  of  algorithm  class  names  and  their  corre¬ 
sponding  executable  image  file  names.  setupMainMenuO  reads  the  clnss  names  into 
the  classStrings  array  used  to  define  menu  items.  It  reads  the  executable  filenames 
into  the  classPrograms  array  used  by  aaarfWindows.c  to  execute  the  animations. 

void  setupMainMenu() 
caddr.t  menuHelp(Menu,  MenuJtem) 

Table  4:  Function  Prototypes  for  aaarfMenu.c 
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3.3  aaarfControl.c 


This  module  creates  and  manages  the  central  control  panel.  Table  5  lists  the  functions 
implemented  in  aaarfControl.c. 

setupCentralControlO  registers  centraiControlDispatchO  with  the  Notifier. 
openControlPanelO  is  registered  by  setupMainMenuO  in  aaarfMenu.c. 

centraiControlDispatchO  haindles  most  panel  events  internally,  but  calls 
closeControlPanelO  and  controlHelpO  to  close  the  panel  eind  display  a  help 
screen.  It  uses  aaarf  Announce O  to  send  control  commands  to  the  active  algorithm 
animations. 


void  setupCentralControl() 

void  centralControlDispatch{PanelJtem,  struct  inputevent*) 
caddr.t  openControlPanel(Menu,  Menu_item) 
void  closeControlPanelO 
void  controlHelpQ _ 


Table  5:  Function  Prototypes  for  aaarfControl.c 
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3.4  aaarfEnvironment.c 


This  module  creates  and  manages  the  AAARF  environment  save  and  restore  feature. 
The  functions  implemented  in  this  module  are  listed  in  Table  6. 

In  setupEnvironmenlPeiJielO,  the  initial  AAARF  environment  path  is  set  to  the 
value  of  the  AAARFENV  environment  variable,  if  it  exists  and  is  a  valid  directory. 
Otherwise  the  initial  path  is  set  to  the  user’s  current  working  directory. 

setupEnvironmentPanelO  registers  environmentHelpO ,  buildMenuO, 
environmentDispatchO ,  closeEnviroiunentPanel () ,  and  getSelectionO  with 
the  Notifier.  createMainMenuO  registers  openEnvironmentPanelO .  The  file  and 
environment  selectors  are  associated  with  a  menu.  buildMenuO  is  associated  with 
each  of  the  menus  and  getSelection  is  associated  with  each  of  the  selectors. 

Since  the  paths  and  files  are  constantly  changing,  the  path  and  file  menus  cannot 
reliably  be  built  until  immediately  before  they  are  displayed.  When  the  path  or 
menu  selector  icons  are  activated,  the  buildMenuO  function  is  called  to  create  the 
appropriate  menu.  First,  all  the  old  menu  items  are  destroyed.  Then  the  new  menu 
items  are  created  from  the  current  pathNames  and  f  ileNames  lists. 

pathNames  and  fileNames  are  built  by  calls  to  getSubdirectoriesO  and 
getDirectoryO .  The  name  lists  are  built  when  the  environment  panel  is  opened 
and  after  every  file  operation. 

The  environmentDispatchO  function  handles  all  the  file  transactions  and  error 
checking. 


void  setupEnvironmentPanelO 

void  environmentDispatch(Panelitem,  struct  inputevent*) 
caddr_t  openEnvironmentPanel(Menu,  MenuJtem) 

void  closeEnvironmentPanel(PajielJtem,  struct  inputevent*) 
Menu  buildMenu(Menu,  Menu_generate) 
int  getSelection(Paneiitem,  Event*) 
void  environmentHelp(Paneljtem,  struct  inputevent*) 


Table  6:  Function  prototypes  for  aaarfEnvironment.c 
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3.5  aaarfWindows.c 

This  module  opens,  closes,  and  monitors  algorithm  windows.  Communication  with 
the  algorithm  processes  is  via  UNIX  sockets.  The  ALG_WINDOW  and  AAARr -STATE  data 
structures  are  used  to  manage  the  algorithm  windows.  Table  7  lists  the  functions 
implemented  in  this  module  and  Table  8  presents  the  data  structure  definitions. 

createMainMenuO  registers  openAlgorithmWindowO ,  aaarf IconifyO ,  and 
aaarfKillO  with  the  Notifier.  aaarfChildMonitorO  is  registered  as  the  termi¬ 
nation  notify  .procedure  for  each  algorithm  window  process. 

Both  openAlgorithmWindowO  and  restoreEnviromnent  ()  fork  algorithm  vdn- 
dow  processes.  They  get  a  socketpair,  fork  a  process,  send  the  process  some  setup 
data,  and  update  aaarfState. 

aaarfChildMonitorO  is  notified  each  time  a  child  process  terminates.  It  updates 
the  aaarfState.  This  function  is  not  called  when  a  child  process  is  killed  (UNIX 
killO  function),  provided  the  function  that  kills  the  child  waits  (UNIX  wait() 
function)  for  the  child  process  to  terminate. 

AAARF,  all  AAARF  panels,  all  open  algorithm  windows,  and  all  their  open  panels 
are  iconified  and  deiconified  by  aaarf  IconifyO. 

aaarf  Announce  O  provides  a  channel  for  sending  commands  to  all  algorithm  pro¬ 
cesses.  Typical  commands  are  ICONIFY,  GO,  STOP,  and  RESET.  It  always  waits 
for  an  acknowledgment. 

saveEnvironment  0  and  restoreEnviromnent  ()  are  the  only  other  functions 
that  communicate  directly  with  the  algorithm  window  process.  They  also  write  and 
read  environment  parameters  to  and  from  disk  files. 

killWindowO  is  used  to  kill  algorithm  window  processes.  It  uses  the  UNIX 
killO  function.  After  killing  a  process  it  uses  the  UNIX  wait4()  function  to  wait 
for  the  process  to  terminate. 
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void 

setupAlgorithmWindows() 

caddr-t 

openAlgorithmWindow(Menu,  MenuJtem) 

int 

aaarf  Announce(int) 

Notify  .value 

aaarfChildMonitor(Notify .client,  int,  union  wait*,  struct  rusage*) 

MenuJtem 

aaarficonify (MenuJtem,  Menu.generate) 

void 

saveEnvironment(int) 

void 

restoreEnvironment(int) 

caddr.t 

aaarfKill(Menu,  MenuJtem) 

void 

killWindow(int) 

Table  7;  Function  Prototypes  for  aaarf Windows,  c 


typedef  struct 

{ 

int  open; 
int  pid; 
int  socket; 
int  clciss; 

} 

ALG-WINDOW; 

typedef  struct 

{ 

ALG-VTNDOW  axgWindow[MAX_ALG.WINDOWS]i 

int  numbcrOpcnWindows; 

int  CCopen; 

int  CCx; 

int  CCy; 

} 

AAARF_STATE; 


Table  8:  aaar /Windows. c  Data  Structures 
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4  Class- Common  Library 

Each  algorithm  class  that  AAARF  calls  is  actually  a  stand  alone  process.  Without  the 
communication  links  to  AAARF,  the  process  could  be  executed  without  the  AAARF 
main  process.  Every  algorithm  class  process  has  the  following  common  feature': 

•  Main  function  gets  setup  parameters  from  AAARF, 

•  Creates  base  window  for  animation, 

•  Creates  the  mcister  control  panel, 

•  Creates  the  algorithm  window  menu, 

•  Creates  the  four  animation  canvases  (views), 

•  Creates  the  animation  recorder, 

•  Creates  the  status  display, 

•  Runs  the  background  process, 

•  Paints  the  active  canvases, 

•  Enters  the  SunView  main  loop. 

The  AAARF  class-common  library  presents  client-programmers  a  framework  for 
developing  new  algorithm  animations  by  providing  all  the  common  functions.  The 
client-programmer  simply  develops  the  class-specific  input,  algorithm,  view,  and  con¬ 
trol  functions.  Because  the  clauis-common  library  depends  on  some  class-specific  data 
structures,  linkable  object  code  is  not  provided,  only  source  code.  The  library  must 
be  recompiled  for  each  new  algorithm  class.  This  limitation  could  be  eliminated  in  a 
future  version  of  AAARF. 

Not  only  does  the  AAARF  class-common  library  make  animation  development 
easier  for  client-programmers,  it  adso  forces  a  consistent  animation  interface  for  the 
end-user.  Every  algorithm  class  supports  the  same  set  of  tools,  and  those  tools  work 
identically  for  every  algorithm  class.  After  animating  one  algorithm,  end-users  can 
animate  any  algorithm,  regardless  of  the  algorithm  cleiss  or  its  client-programmer. 
The  class-common  library  also  ensures  a  consistent  communications  interface  with 
the  AAARF  main  process. 

The  source  code  for  the  AAARF  class-common  library  is  in  the  lib  subdirectory 
and  consists  of  the  following  files: 
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•  aaar f Common. c  Creates  the  base  window  for  the  algorithm  class.  Creates  the 
algorithm  window  menu  and  the  animation  canvcises.  It  also  handles  some  other 
miscellaneous  initialization  tasks. 

•  aaarfM aster,  c  Creates  the  master  control  panel  and  sets  up  the  control  section 
of  the  panel. 

•  aaar /Recorder,  c  Creates  the  animation  recorder.  It  also  provides  the  primary 
interface  to  AAARF. 

•  aaarfViews.c  Sets  up  the  view  section  of  the  master  control  panel  and  creates 
the  status  display.  Handles  the  view  resizing  and  repainting  and  manages  the 
animation. 

•  aaarf Utilities. c  This  is  a  set  of  functions  used  by  the  AAARF  main  process  as 
well  as  the  animation  processes. 

Each  module  has  a  corresponding  header  file  in  which  the  module’s  functions, 
globals,  and  data  structures  are  declared.  Each  of  the  five  modules  are  discussed  in 
the  following  sections. 

In  addition  to  the  module  header  files,  the  following  header  files  define  constants 
and  data  structures  that  are  shared  between  two  or  more  modules: 

•  aaarfDe/ines.h  Defines  system-wide  constants  used  by  all  levels  of  AAARF. 
This  header  fi'e  is  included  in  all  AAARF  source  code  modules.  Table  9  lists 
the  aaarfDe/ines.h  header  fi’e. 

•  aaar/IPC.h  This  file  defines  interprocess  communication  (IPC)  constants  and 
data  structures  shared  by  the  AAARF  main  process  and  the  class-common 
library  modules.  This  header  file  is  listed  in  Table  10. 

•  commonDefines.h  Defines  constants  and  data  structures  shared  by  all  modules 
within  the  class-common  library.  This  header  file  appears  as  Table  11. 

•  classCommon.h  This  file  defines  constants  and  data  structures  defined  by  the 
class-common  library  and  shared  with  the  class-specific  modules.  Table  13  lists 
the  classCommon.h  header  file. 

•  classSpecific.h  This  header  file  is  defined  by  the  class-specific  modules  and  shared 
with  the  class-common  modules.  It  requires  a  specific  set  of  defines  and  data 
structures.  It  is  discussed  in  Section  5  and  listed  in  Table  20. 
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#define  MAX.CLASSES 

50 

#define  MAXj^LG.WINDOWS 

4 

#define  MAX.VIEWS 

4 

#define  MAX^AARF-NAME_SIZE 

15 

#define  MAX_FILES 

100 

#define  MAX .FILENAME^IZE 

256 

#define  MAX_PATHS 

100 

#define  MAX_PATHNAME^IZE 

1024 

#define  DISPLAYED .PATHXENGTH 

25 

#deflne  MAX.COMMAND_LINE_SIZE 

1124 

#define  AAARF_MINIMUM.WIDTH 

500 

#define  AAARFX1INIMUM_HEIGHT 

500 

#define  MAX^TRING_LENGTH 

40 

#define  ASCIIJNTXENGTH 

20 

#define  MIN.WINDOW.WIDTH 

150 

#deflne  MIN  WINDOW_HEIGHT 

150 

#define  OFF 

0 

^define  ON 

1 

#define  FALSE 

0 

#define  TRUE 

1 

#define  STOP 

0 

^define  GO 

1 

#define  CHILD 

0 

#define  PARENT 

1 

#define  DOWN 

0 

^define  UP 

1 

#define  FAILURE 

0 

#define  SUCCESS 

1 

#define  DEFAULT -Sx.IDER.WIDTH 

256 

#define  MAXJIAND 

2147483647 

^define  MAX(a,  b) 

((a  >  b)?a  :  b) 

^define  MIN(a,  b) 

((a  <  b)?a  :  b) 

^define  ABS(a) 

((a  >  0)?a  :  a  *  — 1) 

Table  9:  aaarfDefines.h 
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#define  NEW.WINDOW  -1 

#define  ICONIFY  100 

#define  DEICONIFY  101 

#define  SIMULTANEOUS-GO  200 

#define  SIMULTANEOUS.STOP  201 

#define  SIMULTANEOUS-RESET  202 

#define  ENV-SAVE  300 

#define  SEND-DATA  301 

#define  ACKNOWLEDGE  400 


typedef  struct 

{ 

int  width- 
int  , 

int  xPos; 
int  yPos; 
int  color; 

} 

SETUP-PACKET; 


Table  10;  aaurfIPC.h 
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#define  P_VIEWS 

0 

#define  P.LAYOUT 

1 

#define  P.OPEN 

2 

#deflne  P.WIDTH 

0 

#define  P.HEIGHT 

1 

#define  P  JX:_POS 

2 

#define  P.YJ^OS 

3 

#define  P.COLOR 

4 

#define  P_M.OPEN 

5 

#define  P  J(_POS 

6 

#define  P-M.Y_POS 

7 

#define  P-R.OPEN 

8 

#define  P-R-X_POS 

9 

#define  P-R.Y-POS 

10 

#define  P.S.OPEN 

11 

#define  P-SJC-POS 

12 

#define  P.S.Y-POS 

13 

#define  P.BREAKPOINTS 

0 

#define  P.SINGLESTEP 

1 

#define  P.SPEED 

2 

#define  AUTO_RESIZE 

10 

^define  USERJIESIZE 

2n 

#define  PROP  JIESIZE 

30 

#define  LAYOUT^TACKED 

0 

#define  LAYOUT_SIDE_BS 

1 

#define  LAYOUT-CORNERS 

2 

#define  LAYOUT-FILL 

3 

#dePne  ALG-STOP 

0 

^define  ALG-GO 

1 

Table  11:  comtnonDe fines. h  (1  of  2) 
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#define  ALGJIESET  2 

#define  ALG_TOGGLE  3 

#deflne  ALG_FINISHED  4 

#define  ALG.QUERY  5 

#define  ALG.WIN.OPEN  6 

#define  ALG.WIN.CLOSE  7 

#define  REC.OFF  0 

#deflne  RECJIECORD  1 

#define  REG  J'LAY  2 

#define  REG  .RESTART  3 

#define  REG.REVERSE  4 

#define  REG-FORWARD  5 

#define  REG.QUERY  6 

#define  REGJVTJiEAD  7 

#define  REG  J\T -NEXT  8 

#define  REG  .AT .TAIL  9 

#define  REG-FINISHED  10 

#define  REG-STOP  11 

#define  REG.GO  12 

^define  T.OFF  0 

^define  T.ON  1 

^define  TIMER-NULL  ((  struct  itimerval  *)C) 

typ<^def  struct 

{ 

PARAMS  input; 

PARAMS  algorithm: 

PARAMS  view; 

PARAMS  control; 

PARAMS  window; 

} 

RESTORE-PAK, 


Table  12.  commonDefines.h  (2  of  2) 
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#define  ANIM_FINISHED 
#define  ANIM_BREAK 
#define  ANIM.CONTINUE 


5 

3 

1 


typedef  int  PARAMS[PARAM^IZE]; 

typedef  struct 

{ 

PA  RAMS  input; 

PARAMS  algorithm; 

} 

INIT_PAK; 

typedef  struct 

{ 

Canvas  canvas; 

Pixwin  *pixwin; 
int  open; 
int  view; 
int  width; 
int  height; 
int  xPos; 
int  yPos; 

} 

VIEW-WINDOW; 

typedef  struct 

{ 

VIEW-WINDOW  window[MAX-VIEWS]; 
int  numberOpenViews; 

} 

VIEW -STATE; 


Table  13:  classCoTnmon.h 
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4.1  aaarfCommon.c 

This  is  the  top  level  module  for  the  class-specific  window-based  process.  It  creates  the 
base  algorithm  window,  the  algorithm  window  menu,  and  the  animation  canvases  on 
which  the  views  are  displayed.  Table  14  shows  the  functions  included  in  this  module. 

mainO  creates  the  base  algorithm  window  and  registers 
f rameInterposeDispatchO  to  monitor  window  events.  It  calls  several  functions 
to  create  the  standard  set  of  algorithm  window  tools,  aaarf CommandDispatchO  is 
registered  to  monitor  the  UNIX  socket  to  the  AAARF  main  process. 

fraunelnterposeDispatchO  catches  events  in  the  base  algorithm  frame  before 
they  are  dispatched  to  the  appropriate  function.  Most  events  are  accepted.  If  a  resize 
event  is  detected,  the  old  and  new  sizes  are  recorded  and  the  window’s  current  views 
are  repainted  with  calls  to  resizeAllViewsO  and  repaintAllViewsO. 

aaarf  CommandDispatchO  monitors  a  socket  to  AAARF.  When  commands  are 
received,  the  appropriate  functions  are  called. 

The  algorithm  window  is  iconified  and  deiconified  in  setAlgWindowStateO.The 
state  of  the  animation  and  the  state  and  position  of  the  algorithm  p?ne1s  are  preserved. 

createAnimationCanvasO  creates  the  algorithm  canvases  (view  windows)  and 
registers  canvasInterposeDispatchO  and  canvasEventDispatchO  to  handle 
events  within  a  canvas.  canvasInterposeDispatchO  catches  canvas  resize  events 
and  redisplays  all  views.  canvasEventDispatchO  catches  middle  and  left  mouse 
button  clicks  within  the  canvcises  to  update  elementOf  Interest  and  control  the  an¬ 
imation. 

createAlgMenuO  creates  the  algorithm  window  menu  and  registers 
menuDispatchO  with  the  Notifier.  algWindowHelpO  shows  a  help  screen  for  the 
algorithm  window  menu  and  algKillO  destroys  the  algorithm  window. 

setAlgWindowTitleO  is  called  frequently  by  several  different  functions  to  set  the 
algorithm  window  title  bar  to  reflect  the  current  algorithm  name  and  recorder  status. 

openFontsO  opens  an  array  of  fonts  for  writing  cext  to  canvases,  fonts [O] 
through  fonts  [5]  are  empty.  The  remaining  cirray  elements  point  to  fonts  whose 
point  size  is  equal  to  their  airray  index. 
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int 

main(int,  char*) 

Notify.value 

frameInterposeDispatch(fraine,  Event,  Notify -arg,  Notify_event-type) 

Notify -value 

aaarfCommandDi3patch(Notify .client,  int) 

void 

setAlgWindowState(int) 

void 

createAnimai,ionCanvas(int) 

Notify -value 

canvasInterposeDispatch(frame,  Event,  Notify .arg,  Notify-event.type) 

Notify -Value 

canvasEventDIspatch(Window,  Event*,  caddr.t) 

void 

createAlgMenu() 

caddr-t 

nienuDispatch(Menu,  Menuitem) 

void 

set  Alg  WindowTitle( ) 

void 

openFonts() 

void 

algWindowHelpO 

void 

algKiUO 

Table  14;  Function  Prototypes  for  aaarfCommon.c 
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4.2  aaarfMaster.c 


This  module  creates  the  meister  control  p^mel.  The  meister  control  panel  is 
divided  into  four  sections:  control,  input,  algorithm,  and  view.  The  class- 
common  library  provides  the  control  amd  view  sections  with  some  help  from  the 
class-specific  setBreaikPointsItemsO  and  setVie»Najnes()  functions.  The  input 
and  algorithm  sections  are  provided  by  the  class-specific  addInputSectionO  and 
addAlgorithmSectionO  functions.  The  functions  included  in  aaarfMaster.c  are 
listed  in  Table  15. 

createMasterControlO  creates  the  master  control  panel.  It  calls  functions  to 
setup  the  four  sections  of  the  panel.  It  registers  the  masterEventDispatchO  with 
the  Notifier  to  monitor  the  Help  and  Close  buttons. 

addControlSectionO  sets  up  the  control  section  of  the  master  control  panel.  It 
registers  controlEventDispatchO  with  the  Notifier. 

The  getControlParametersO  and  setControlPairametersO  functions  are  used 
to  save  and  set  control  parameters  for  the  animation  recorder  and  environment  control 
functions.  They  both  use  the  PARAMS  structure  for  parameter  storage.  PARAMS  is 
simply  an  array  of  integers.  The  size  of  the  array  is  set  by  the  client-programmer  in 
the  claiss-specific  header  file. 


void  createMcisterControl() 

void  masterEventDispatch(Paneljtem,  struct  inputevent*) 
int  addControlSection(Panel,  int) 
void  controlEventDispatch(PanelJtem,  struct  inputevent*) 
void  getControlParameters(PARAMS) 
void  setControlPar2uneters(PARAMS) 


Table  15:  Function  Prototypes  for  aaarfMaster.c 


4.3  aaarfRecorder.c 

This  module  implements  the  animation  recorder  and  manages  parameter  exchanges 
with  AAARF.  Table  16  lists  the  functions  implemented  in  this  module  and  Table  17 
presents  the  data  structures  defined  for  this  module.  The  IE_PACKET  structure  pro¬ 
vided  by  the  client-programmer  in  classSpecific.h  (see  Table  20)  and  the  SETUP_PACKET 
structure  defined  in  aaarfIPC.h  (see  Table  10)  are  also  used. 

createRecorderO  creates  the  recorder  panel  eind  registers  recordDispatchO, 
buildMenuO,  and  getSelectionO  with  the  Notifier.  The  recorder’s  path  and 
recording  selectors  work  exactly  like  the  path  and  environment  selectors  of  the  envi¬ 
ronment  control  panel  (Section  3.4). 

Recordings  are  stored  in  a  linked  list  structure  (see  Figure  17).  The  list  is  managed 
with  three  pointers;  head,  tail,  and  next.  playlEO  provides  TEs  by  traversing  the 
linked  list.  The  list  is  doubly  linked,  but  the  current  version  of  AAARF  does  not 
support  reverse  playback.  Recordings  are  created  with  savelEO  which  accepts  an 
IE,  mallocOs  a  new  node,  and  adds  the  IE.  restartRecordingO  sets  the  next 
pointer  to  the  head  of  the  list,  f  reeRecorderMemoryO  frees  the  memory  previously 
allocated  for  a  recording.  readRecordingO  and  writeRecordingO  are  used  for 
reading  and  writing  recordings  to  disk. 

setRecorderStateO  controls  the  recorder  functions  and  maintains  state  infor¬ 
mation  regcirding  the  animation  recorder. 

readParametersO  and  restoreParametersO  are  used  to  restore  the  animation 
state.  getParzunetersO  and  sendParametersToAAARFO  eu’e  used  to  save  the  ani¬ 
mation  state. 
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void  createRecorder() 

void  recordDispatch(PaneIJtem,  struct  inputevent*) 
Menu  buildMenu(Menu,  Menu_generate) 
int  getSelection(Panelitem,  Event*) 
int  setRecorderState(int) 
void  readPajaJTieters(SETUP -PACKET,  int,  int) 
void  restorePaurametersO 
void  getPcLrameters() 
void  sendParaineter8ToAAARF(int) 
void  readRecording(int) 
void  writeRecording(int) 
void  restartRecordingO 
void  freeRecorderMemoryO 
IE_PACKET  *pIayIE() 

void  saveIE(IE_PACKET*) 
void  recorderHelpO 

Table  16:  Function  Prototypes  for  aaar f Recorder,  c 


typedef  struct  lEnode  IE_NODE; 

struct  lEnode 

{ 

IE_NODE  *lastIE; 
lE-PACKET  lEpacket; 
lE-NODE  *nextIE; 

} 
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4.4  aaarfViews.c 

This  module  sets  up  the  view  section  of  the  master  control  panel,  creates  the  status 
display  panel,  and  manages  the  animation  views.  Table  18  lists  the  functions  included 
in  this  module.  The  VIEW_STATE  data  structure  is  used  to  manage  the  view  windows. 
This  structure  is  defined  in  clasaCommon.h  (Table  13). 

addViewSectionO  creates  the  view  section  of  the  master  control  panel  and 
registers  viewDispatchO  with  the  Nctifier.  The  getViewParametersO  and 
setViewParametersO  functions  are  used  by  the  recorder  and  the  environment  con¬ 
trol  to  get  and  set  view  parameters.  restoreVieusO  is  used  to  restore  a  particular 
view  window  configuration  after  a  restore  operation. 

createStatusDisplayO  creates  the  status  display  and 
register:  stat’.’sDi?pat<-h()  with  the  Notifier.  It  calls  buildStatusDisplayO  to 
build  the  class-specific  portion  of  the  status  display. 

mainO  associates  a  polling  timer  with  animateTheAlgorithmO ,  which  is  the 
heart  of  the  animation.  It  gets  an  IE,  processes  the  IE,  and  updates  the  dis¬ 
plays.  The  polling  timer  is  controlled  by  setAlgTimerC);  it  is  at  the  end  of  ev¬ 
ery  pass  through  animateTheAlgorithmO.  The  display  state  is  controlled  and 
managed  by  setDisplayStateO.  It  is  checked  at  the  start  of  every  pass  through 
animateTheAlgorithmO;  if  the  display  state  is  not  set  to  ALG.GO,  nothing  happens 
in  that  pass. 

resizeAllViewsO  sizes  all  open  views  according  to  an  argument  from  the  calling 
function  and  the  current  view  parameters. 

int  addViewSection(Panel,  int) 
int  viewDispatch(PeinelJtem,  unsigned  int.  Event*) 
void  getViewPaxameters(PARAMS) 
void  setViewParameters(PARAMS) 
void  restoreViews() 
void  resizeAllViews(int) 
int  setDisplayState(int) 
int  setAlgTimer(int) 
void  createStatusDisplayO 

void  statusDispatch(Panel-item,  struct  inputevent*) 

Notify  .value  animateTheAIgorithm(Notifyxlient,  int) 

Table  18:  Function  Prototypes  for  aaarfViews.c 
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4.5  aaarfXJtilities.c 

This  module  consists  of  functions  that  are  common  to  both  the  AAARF  main  process 
and  the  algorithm  animation  processes.  The  functions  are  listed  in  Table  19. 
getScreenResolution  sets  the  screen  height,  width,  and  depth. 
pamelFrameEventDispatchO  is  a  notify  procedure  which  suppresses  the  default 
SunView  menu  from  popping  up  on  panels.  It  is  associated  with  all  panels  used  in 
AAARF. 

characterFilterO  is  used  to  filter  user  input  from  the  keyboard;  it  only  passes 
numbers  and  alphabetic  characters. 

getDirectoryO  and  getSubdirectoriesO  generate  a  list  of  files  and  paths 
respectively. 

userWarningO  displays  an  alert  message  with  the  argument  provided. 


void 

getScreenResolution(mt*,  int*,  int*) 

Notify  .value 

paneiFrameEventDi8patch(Frame,  Event*,  Notify .arg,  Notify jevent-type) 

Panel.setting 

characterFilterfPanelJtem,  Event*) 

int 

getDirectory(char*,  char*,  char*) 

int 

getSubdirectories(char*,  char*) 

void 

user Warning( Frame,  char*) 

Table  19:  Function  Prototypes  for  aaarf Utilities. c 
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5  Class- Specific  Functions 

The  most  difficult  part  of  developing  an  algorithm  animation  is  determining  how 
to  meaningfully  represent  an  algorithm’s  state.  There’s  no  procedures  or  rules  for 
milking  such  a  determination;  it’s  usually  best  to  start  with  the  familiar  static  rep¬ 
resentations  found  in  text  books.  After  creating  a  simple  view,  it’s  easier  to  devise 
more  -nmplex  and  possibly  more  interesting  views.  Determining  the  nature  of  the 
graphical  representation  is  a  matter  of  creativity;  this  section  is  more  concerned  with 
the  mechcinics  of  presenting  the  view. 

The  AAARF  class-common  libr«iry  provides  client-programmers  a  framework  for 
developing  new  algorithm  animations.  This  section  describes  the  class-specific  re¬ 
quirements  of  the  framework  and  presents  recommendations  for  using  the  framework 
to  develop  new  algorithm  animations.  The  ArraySort  algorithm  class  is  used  as  an 
example  throughout  this  section.  The  source  code  for  the  ArraySort  class  is  included 
in  the  AiTaySort  subdirectory  of  the  AAARF  distribution. 

Section  5.1  describes  how  to  set  up  a  working  directory  to  begin  development  of 
a  new  algorithm  animation.  Section  5.2  recommends  a  method  for  testing  algorithm 
animations  under  development.  Section  5.3  outlines  the  general  requirements  for  a 
new  algorithm  animation.  The  remainder  of  the  section  describes  the  requirements 
in  more  detail. 

•  The  program  development  methods  presented  in  this  section  are  just  sugges¬ 
tions.  Experienced  programmers  may  prefer  variations  of  these  methods  or  even 
a  completely  different  approach  to  program  development.  However,  adherence 
to  the  suggested  methods  insures  some  degree  of  uniformity  among  algorithm 
class  implementations,  making  it  easier  for  any  programmer,  regardless  of  their 
experience  level,  to  modify  or  complete  any  another  programmers  project. 
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5.1  Creating  a  )rking  Directory 

Begin  by  creating  a  wording  directory.  Copy  the  contents  of  the  ArraySort  directory 
to  use  35  a  template  for  the  development.  Either  edit  the  ArraySort  files  or  create 
new  files  using  the  /lrrai/5ort  files  as  a  guide.  In  either  case,  existing  algorithm  classes 
are  probably  the  best  guide  for  developing  new  algorithm  classes.  Use  the  UNIX  In 
command  to  create  a  symbolic  link  to  the  A  A  ARE  class-common  library.  Figure  9 
shows  typical  commands  for  setting  up  a  working  directory;  don’t  take  this  example 
too  literally;  the  local  AAARF  directory  may  be  in  a  different  path. 

DALI<1>  mkdir  BinPack 
DALI<2>  cd  BinPack 

DALI<3>  cp  /usr/local/src/aaarf /ArraySort/*  . 

DALI<4>  In  -3  /usr/local/src/aaarf /lib/* .c  . 

DALI<5>  In  -s  /usr/local/src/aaarf/lib/* .h  . 

Figure  9:  Creating  a  Working  Directory  for  the  Bin  Packing  Class 

5.2  Testing  a  New  Algorithm  Class 

Test  new  animations  by  creating  a  local  AAARF  class  file  that  includes  the  name  and 
path  of  the  algorithm  class  under  development.  Copy  the  default  AAARF  class  file 
to  a  local  file,  add  the  new  algorithm  class  to  the  local  file’s  list  of  classes,  and  set  the 
AAARFCLASSES  environment  variable  to  the  local  AAARF  class  file.  Now  when 
AAARF  is  evoked,  it  uses  the  locail  AAARF  cleiss  file.  This  allows  programmers 
to  work  on  animations  without  interfering  with  other  AAARF  users.  When  the 
animation  is  ready  for  public  distribution,  add  its  name  and  path  to  the  default 
AAARF  classes  file. 
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5.3  General  Requirements 

There  are  three  categories  of  requirements  for  developing  an  algorithm  class: 

•  The  class-common  framework  requires  19  class-specific  functions,  5  constant 
definitions,  and  1  data  structure  definition.  The  functions  can  be  distributed 
among  any  number  of  arbitrarily  named  modules,  but  the  constants  and  the 
data  structure  must  be  in  a  file  cadled  classSpecific.h  (see  Section  5.4). 

•  There  must  be  a  paintXXXO  and  an  updateXXXO  function  for  every  view  that 
is  implemented. 

•  There  must  be  a  background  process  that  implements  the  algorithms,  generates 
input  for  the  algorithms,  and  maintains  a  communications  link  to  the  window- 
bzised  process  for  reporting  lEs  generated  by  the  adgorithms. 

In  general,  the  background  process  consists  of  a  main()  function  to  establish 
communications  with  the  window-based  process  and  to  call  the  input  generator 
and  the  appropriate  algorithm,  an  IE  Dispatcher  to  send  interesting  events 
to  the  window-based  level,  and  the  algorithm  functions.  Figure  10  shows  the 
general  structure  of  the  background  process. 


I 

I 
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Figure  10;  Background  Process  Structure 
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5.4  Class- Specific  Header  File 

The  AAARF  clciss-common  functions  need  five  class-specific  constants  and  one  class- 
specific  data  structure.  The  data  structure  is  used  to  report  lEs  from  the  background 
process  and  to  record  and  playback  lEs  on  the  animation  recorder.  There  is  no  limi¬ 
tation  to  the  size  or  contents  of  che  structure,  but  it  must  be  of  the  type,  IE_PACKET. 
Table  20  shows  the  classSpecific.h  header  file  for  the  ArraySort  algorithm  class. 

The  five  constants  are: 

•  CLASS _NAME  The  name  of  the  algorithm  class. 

•  CLASS_ICON  The  file  name  of  the  class  icon,  iconedit,  an  icon  editor  available  on 
most  Sun  workstations,  can  be  used  to  create  an  icon.  Alternatively,  any  icon 
in  the  icons  subdirectory  can  be  use. 

•  TIMER-SCALE  Sets  a  multiplier  for  the  number  of  milliseconds  between  calls  to 
animat eTheAlgorithmC).  It  may  take  a  few  iterations  to  get  this  number  just 
right;  3000  is  a  good  starting  point.  The  number  must  be  greater  than  zero. 

•  TIMERjOFFSET  Sets  the  minimum  number  of  milliseconds  between  calls  to 
animateTheAlgorithmC).  This  number  must  also  be  greater  than  zero;  one 
is  a  good  starting  point. 

•  PARAM-SIZE  Sets  the  number  of  elements  in  the  parameter  storage  array. 
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“ArraySort” 
Array  Sort,  icon” 

3000 
1 

1 

50 

typedef  struct 

{ 

int  type; 
int  index  1; 
int  index2; 

} 

lE-PACKET; 


#define  CLASS-NAME 
#define  CLASS JCON 

#define  TIMER-SCALE 
#define  TIMER-OFFSET 

#define  DEFAULT  .VIEW 
#define  PARAM.SIZE 


Table  20:  Sample  classSpecific.h  from  the  ArraySort  Class 
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5.5  Input  Functions 

Three  input  functions  are  required  by  the  clciss- Common  library;  they  are  listed  in 
Table  21.  addInputSectionO  uses  SunView  painel  items  to  provide  a  mechanism  for 
catting  parameters  to  the  input  generator.  The  mzister  control  panel  handle  and  a 
row  number  within  the  panel  are  passed  to  the  function.  Panel  items  are  positioned 
beginning  at  the  row  number.  After  all  pcinel  items  are  placed,  the  row  number 
at  which  the  next  panel  section  can  begin  is  returned.  Notify  procedures  for  the 
input  section  are  not  required,  but  may  be  used  if  deemed  necessary  by  the  client- 
programmer. 

getlnputPaxametersO  and  setlnputParametersO  provide  a  means  for  saving 
and  setting  parameters  to  support  the  recorder  and  the  environment  controller. 


int  addInputSection(Pajiel,  int) 
void  getlnputParameters(PARAMS) 
void  setlnputParameters(PARAMS) 


Table  21:  Required  Input  Functions 

5.6  Algorithm  Functions 

Four  algorithm  functions  are  required  for  the  class-common  library;  they  are  listed 
in  Table  22.  One  function  is  for  adding  algorithm  panel  items  to  the  master  control 
panel,  and  two  functions  are  used  to  save  and  restore  the  algorithm  p«irameters. 
The  fourth  function,  getAlgorithmNaoe  is  used  to  post  the  algorithm  name  on  the 
algorithm  frame  title  b^l^.  It  returns  a  pointer  to  the  currently  selected  algorithm 
name.  A  notify  procedure  for  the  algorithm  pemel  is  not  required,  but  can  be  used  if 
deemed  necessary  by  the  client-programmer. 


int  addAlgorithmSection(Panel,  int) 
char  *getAlgorithmName() 
void  getAlgorithmParameters(PARAMS) 
void  setAlgorithmPeu'ameters(PARAMS) 


Table  22:  Required  Algorithm  Functions 
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5.7  View  Functions 


The  clciss- common  library  only  requires  three  view  functions,  but  for  every  view  sup¬ 
ported  by  an  algorithm  class,  there  must  also  be  a  function  to  paint  and  update 
the  view  within  an  arbitrarily  sized  view  window.  Table  23  lists  the  required  view 
functions.  When  one  view  requires  painting  or  updating,  they  all  do;  thus  the  two 
functions  paintAllViewsO  and  updateAllViewsf).  Since  the  update  operation  de¬ 
pends  on  the  current  IE,  updateAllViewsO  requires  an  IE  as  an  input  argument. 

processIEO  accepts  the  current  break  point  setting  and  the  current  IE  and 
returns  the  animation  state;  stop,  continue,  or  finished.  Within  the  routine,  the 
animation  data  structure  is  modified  in  accordance  with  the  current  IE. 

int  processIE(int,  IE_PACKET*) 
void  paintAlIViewsf) 
void  update  AIlViews(IE-PACKET*) 

Table  23:  Required  View  Functions 
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5.8  Status  Functions 

Four  status  functions  are  required;  they  are  listed  in  Table  24.  The  status  functions 
share  several  global  variables  with  the  view  functions,  so  they  are  typically  grouped 
together  in  the  same  module.  ArraySortView.c  is  an  examples  of  a  module  that 
combines  the  view  and  status  functions. 

buildStatusDisplayO  creates  the  clciss-specific  entries  in  the  status  display.  The 
status  display  handle  and  a  row  number  «ire  input  parameters.  statusHelpO  pro¬ 
vides  a  help  screen  for  the  status  display. 

updateElementQf  Interest ()  is  closely  related  to  the  view  functions  in  that  it 
must  determine  which  element  or  aspect  of  an  animation  a  user  has  selected. 

updateStatusO  is  also  related  to  the  view  functions  -  processIEC)  updates  the 
appropriate  variables  for  the  status  display.  The  updates  are  applied  to  the  status 
panel  when  this  function  is  called. 

void  buildStatusDisplay(Panel,  int) 
void  updateElementOfInterest(int,  int,  Window) 
void  updateStatusO 
void  statusHelp(Frame) 

Table  24:  Required  Status  Functions 
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5.9  Control  Functions 


There  are  five  control  functions  required  by  the  class-common  library.  They  are  listed 
in  Table  25.  The  setViewItemO  and  setBreakPointlteoO  functions  are  used  to 
set  the  class-specific  portions  of  the  view  section  and  control  section  of  the  master 
control  panel.  masterHelpO  provides  the  class-specific  help  screen  for  the  master 
control  panel. 

runAlgorithmInBackgroundO  is  an  important  function  that  manages  the  algo¬ 
rithm  state  structure  and  the  class-specific  background  process. 

getlEO  is  the  communications  link  to  the  background  process.  It  sends  an 
lErequest  and  receives  the  next  IE. 


void 

runAlgorithmInBackground( ) 

lEJ’ACKET 

♦getlEO 

void 

setBreakPointltem(Panelitem) 

void 

setViewItem(PaneUtem) 

void 

masterHelpO 

Table  25;  Required  Control  Functions 
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6  AAARF  Projects 

This  section  presents  suggestions  for  AAARF  extensions  and  animation  projects. 

1.  Extend  the  AAARF  class  file  to  include  other  configuration  variables  that  are 
currently  either  compile  time  defines,  hard-coded  defines,  or  environment  vari¬ 
ables.  For  example,  maximum  number  of  windows;  maximum  number  of  views; 
maximum  and  minimum  window  size;  default  recording  and  environment  paths; 
default  algorithm  window  color  codes;  etc.  Most  likely,  two  configuration  files 
are  required;  one  for  the  AAARF  administrator  and  one  for  the  user. 

2.  Implement  a  “snap”  option  which  forces  the  width,  height,  and  position  of 
windows  to  be  a  multiple  of  some  number  of  pixels.  This  feature  makes  it  easier 
to  create  windows  of  the  same  size  and  to  align  them  neatly  for  comparisons. 

3.  Modify  the  animation  recorder  such  that  reverse  playback  is  supported.  This 
allows  the  end-user  to  immediately  review  an  interesting  part  of  a  (recorded) 
zmimation,  without  restarting  the  recording. 

4.  Extend  the  animation  recorder’s  capabilities  such  that  every  animation  is  always 
recorded.  This  allows  the  user  to  use  the  reverse  button  at  any  time  during  the 
animation.  An  interesting  part  of  an  animation  could  be  reviewed  immediately 
(currently,  the  user  must  Weiit  for  the  algorithm  to  finish  before  playing  the 
recording).  When  the  user  hits  the  reverse  button,  the  recorder  provides  lEs  to 
the  view  functions;  the  background  procedure  continues  to  wait  with  its  next 
IE.  If  the  animation  returns  to  the  point  at  which  the  reverse  button  was  hit, 
lEs  are  again  retrieved  from  the  background  procedure. 

5.  Extend  the  capability  of  the  recorder  such  that  it  records  control  events.  For 
example,  detect  and  record  speed  changes,  changes  in  the  breeik  point  setting, 
user  requested  stops,  etc.  This  permits  end-users  to  create  recordings  that 
emphasize  a  particular  event  or  set  of  events  within  an  animation. 

6.  Develop  a  linkable  library  of  animation  objects  similar  to  that  developed  by  John 
Stasko  in  TANGO  [6].  The  library  should  provide  a  set  of  primitive  graphic  ob¬ 
jects  Md  functions  to  support  smooth  animation  of  the  objects  between  two 
points  or  along  a  predetermined  path.  This  could  greatly  simplify  the  develop¬ 
ment  of  the  view  functions,  arguably  the  most  grueling  programming  task  for 
the  client-programmer. 

7.  Modify  the  AAARF  class-common  library  such  that  it  is  a  linkable  library. 
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8.  Add  a  current  state  indicator  to  the  algorithm  window  structure.  The  indicator 
reflects  the  current  state  of  the  algorithm  (running,  stopped,  finished,  etc)  and 
the  current  state  of  the  recorder  (recording,  reverse,  forward,  paused,  etc). 
Unlike  the  status  display  panel  which  may  be  opened  or  closed,  this  indicator  is 
always  displayed.  The  information  can  appear  on  the  title  bar  or  within  some 
reserved  area  in  the  algorithm  window. 

9.  Modify  AAARF’s  color  table  usage  so  that  pixrect  patterns  are  used  in  addi¬ 
tion  to  color.  This  should  provide  more  interesting  displays  on  monochrome 
monitors. 

10.  Develop  a  bin  sorting  algorithm  claas.  Algorithms  should  include  first-fit,  best- 
fit,  worst-fit. 

11.  Develop  a  tree  searching  program  that  animates  various  type  of  search  algo¬ 
rithms:  depth-first,  breadth-first,  etc. 

12.  Animate  several  numerical  approximation  methods  such  as  finding  roots,  inte¬ 
gration,  lecist  common  denominator. 

13.  Animate  the  “Drinking  Philosophers”  problem  using  a  petri  net  representation. 
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Appendix  E.  Source  Code 


The  AAARF  source  code  is  included  in  Volume  2. 
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Traditionally,  software  engineers  have  described  algorithms  and  data  structures  using  graphical 
representations  such  as  flow  charts,  structure  charts,  and  block  diagrams.  These  representations 
can  give  a  static  general  overview  of  an  algorithm,  but  they  fail  to  fully  illustrate  an  algorithm’s 
dynamic  behavior.  Researchers  have  begun  to  develop  systems  to  visualize,  or  animate,  algorithms 
in  execution.  The  form  of  the  visualization  depends  on  the  algorithm  being  examined,  the  data 
structures  being  used,  and  the  ingenuity  of  the  programmer  implementing  the  animation. 

This  study  chronicles  the  development  of  the  AFIT  Algorithm  Animation  Research  Facility 
(AAARF).  The  goal  of  the  study  is  (1)  to  develop  a  method  for  developing  algorithm  animations 
and  (2)  to  develop  an  environment  in  which  the  animations  can  be  displayed.  The  study  empha¬ 
sizes  the  application  of  modern  software  engineering  techniques.  The  development  follows  a  classic 
life-cycle  software  engineering  paradigm:  requirements,  design,  implementation,  and  testing.  An 
object-oriented  approach  is  used  for  the  preliminary  design.  The  system  is  implemented  with  the  C 
programming  language  on  a  Sun  workstation  and  uses  the  SunView  window-based  environment. 

A  framework  is  proposed  for  developing  algorithm  animations  that  minimizes  the  development 
time  for  client-programmers.  The  framework  also  ensures  that  end-users  are  presented  a  consistent 
method  for  interacting  with  the  animations.  The  algorithm  animation  environment  provides  end- 
users  with  a  variety  of  control  and  viewing  options:  multiple  algorithms,  multiple  views,  simultaneous 
control  of  algorithms,  and  animation  environment  control.  Three  levels  of  execution  are  used  to 
provide  multiple  algorithm  animations  and  multiple  views  of  algorithms.  The  animation  manager 
and  view  generators  must  reside  on  the  Sun  workstation,  but  the  algorithms  can  reside  on  any 
network-connected  host. 
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